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Abstract 

A requirements engineering artifact is valid relative to the stakeholders of the system-to-be if they agree 
on the content of that artifact. Checking relative validity involves a discussion between the stakeholders 
and the requirements engineer. This paper proposes (i) a language for the representation of information 
exchanged in a discussion about the relative validity of an artifact; (ii) the acceptability condition, which, 
when it verifies in a discussion captured in the proposed language, signals that the relative validity holds 
for the discussed artifact and for the participants in the discussion; and (iii) reasoning procedures to 
automatically check the acceptability condition in a discussions captured by the proposed language. 
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1 Introduction 



A basic question for requirements engineering (re) is how to find out what the stakeholders of a system-to-be 
"really need" [S]. In response, RE stars with the elicitation of requirements, the purpose of which is the 
initial investigation of the goals, functions, and constraints of the system-to-be, as they are stated by the 
stakeholders. Despite the difficulty of making a clear distinction between the various specific tasks that RE 
can involve [5], elicitation is acknowledged to be one of the three fundamental tasks in re, in addition to 
validation and modeling/specification [14\ I22j. 

Modeling/specification depends heavily on elicitation, for it is elicitation that provides the application 
domain- and project-specific information that is, potentially in a changed form, represented in re artifacts 
(i.e., models and specifications). RE artifacts capture the elicited information in a format that lends itself to 
specific analysis, which the stakeholders themselves have difficulty to perform, such as, e.g., the verification 
of the internal consistency of requirements. Neither elicitation, nor modeling/specification can be successful 
without validation. As Goguen and Linde observe, "[t]here are very good reasons why [stakeholders] often do 
not, or cannot, know exactly what they need; they may want to see models, explore alternatives, and envision 
new possibilities" [8]. A key purpose of requirements validation is to seek feedback from the stakeholders 
on re artifacts so as to inform further iterations of elicitation and/or modeling/specification. To check the 
validity of an re artifact is to determine if what it says about the system-to-be is in line with what the 
stakeholders "really need" . 

Problem. The aim of validation is ambitious: through repeated and intertwined performance of validation 
together with elicitation and modeling, we would indeed hope to arrive at re artifacts that capture exactly 
what the stakeholders really need. Such absolute validity should be distinguished from what we call relative 
validity. While the former certainly stands as an ideal to aim for, the latter is achievable in practice and is 
the concern of this paper. 

Relative validity is concerned with whether the stakeholders agree on the content of an RE artifact. Validity 
is in this sense relative to the stakeholders. An RE artifact is therefore valid in this sense if the stakeholders 
agree that what it says about the system-to-be is acceptable to them. Stated otherwise, this form of validity 
will verify if all the concerns, which the stakeholders raised, are answered. 

It is safe to say that we cannot know if the stakeholders agree on an artifact if we do not give them 
the possibility to raise their concerns. The engineer can inform them in this task by providing graphical 
animations of a behavior model [21] . the results of checking of predefined properties on models made from 
parsed text [7] , explicit accounts of (the inconsistencies between) different viewpoints on the system-to-be [14] . 
In each of these cases, the engineer will be producing information to present in a potentially summarized form 
to the stakeholders, and then discuss it. Checking relative validity inevitably leads to a discussion between 
the stakeholders and the requirements engineer. 

Contributions. This paper focuses on the modeling and analysis of a discussion between the stakeholders 
and requirements engineers about the relative validity of an re artifact. By building on contributions in 
design rationale research, argumentation research in artificial intelligence, and graph traversal algorithms, 
our aims are to: (i) provide a simple but expressive propositional model of the explicit exchange of infor- 
mation in what is usually called a discussion; (ii) based on the model of a discussion, propose a condition, 
called the acceptability condition on an artifact (denoted AC), such that if it holds, then it signals that the 
relative validity verifies for that artifact and for the participants in that discussion; and (iii) if a concrete 
discussion is recorded (as is the case when discussions are realized in forum- like applications), then check 
automatically if AC holds at some point in the discussion. To meet these aims, we propose the vlcccptability 
Evaluation framework, henceforth ACE. ACE can be seen as a simple propositional reasoning framework, that 
is independent of the RE method that produces the artifact, and of the application domain. 

Organization. Basic assumptions are first discussed, and a preliminary definition of the acceptability 
condition is proposed ([J3]). The two components of ACE are then presented: the language to record the 
information relevant to the evaluation of acceptability (SJ, and (ii) algorithms for retrieving the recorded 
information and evaluating its acceptability ($5}. The full definition of the acceptability condition is then 
given in light of the complete ACE framework ([}6]). Notes some implementation considerations are then 
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outlined (j}7J| and the related work is discussed (jJHl). We end with a summary of conclusions and point to 
future work 

2 Baseline 

What is typically called a discussion is. roughly speaking, a complex exchange of information between po- 
tentially many participants. Various properties of a discussion can be studied, such as its topic, purpose, 
(dis)organization, and so on. We focus on discussions about re artifacts, the purpose of which is to reach a 
conclusion about the relative validity of the artifacts. We are interested in the specific traits of the structure 
of such discussions. These are the inference, attack, and preference relationships between pieces of informa- 
tion offered in a discussion. Inferences connect premises to conclusions, attacks connect somehow opposing 
information, and preferences compare in terms of desirability the conditions described via the various pieces 
of information offered in the discussion. 

The range of discussions we focus on is not confined to specifc RE methods and artifacts. Leite and Freeman 
[14] observed that "the whole process of [re] is a web of subprocesses, and it is very difficult to make a clear 
distinction between them" . A subprocess in that web amounts to the application of some RE method to 
specific inputs, in order to produce an output, itself fed into the application of another method, and so on. 
To remain general, we can say that the application of any RE method, i.e., any subprocess in the complex 
RE web, fits the abstract input-transformation-output pattern. Namely, in a given application domain D, 
information elicited or produced by another RE method acts as the input Id to a domain-independent re 
method, symbolized by the function T . The latter produces the domain-specific output Od, i.e., Od = T(Ijj). 
E.g., the refinement of a requirement asks for an abstract requirement and domain-specific knowledge as its 
inputs Id, and results in a set of less abstract requirements as its output Ojj, while the transformation T 
establishes the relations, such as consistency, that must verify between inputs and outputs. Observe that Id 
and Od, or any part thereof is clearly an re artifact. Moreover, we can view the application of a method to 
specific inputs, i.e., T(Id) as an artifact itself: there really seems to be no strong argument not to allow the 
participants to discuss the engineer's choice of applying T to Id- 

Discussion performed to the aim of checking the relative validity of the application of an RE method, 
i.e., Od = T(Id), or equivalently, the relative validity of individual artifacts Od, T(Id), and Id, consists of 
offering information in favor or against these, and providing opinions about the relative desirability of the 
offered information. If I agree with you, I can provide additional information to support your position; if 
we disagree, I can offer information against your positions; if I have no further information to offer in favor 
of or against that which has been offered, I can say which of the already present conclusions I prefer to 
others. Od = T(Id) will be acceptable if and only if no information offered against any of the components 
of Od = T(Id) holds by the end of the discussion. Acceptability signals agreement. It is reasonable to 
interpret agreement as relative validity. It is by analysing a discussion that we can determine if there is 
agreement about the artifacts being validated, and thereby if they are valid relative to the participants in 
the discussion. If the parties agree that the given inputs Id transformed by the application of the method 
T give Od, then they agree that Od = Td{Id) holds, so that the given method application is acceptable, 
denoted AC(I D ,T(I D ), D ). 

3 Acceptability Condition 

Definition 3.1. AC. The application of the re method T to the input Id to produce the output Od is 
acceptable, denoted AC{Id,T{Id),Od) if and only if: 

AC(Id) A AC{T{Id)) A AC{Od) (1) 

In order to apply to any method, ACE sees any RE artifact, or part thereof, as a proposition. In concep- 
tualizing a proposition, we follow McGrath's |16| stipulation that propositions "are the sharable objects of 
the attitudes [(i.e., what is believed, desired, etc.)] and the primary bearers of truth and falsity" . Regardless 
then of the syntax and semantics of the RE method deployed to produce an artifact, the artifact itself is a con- 
junction of propositions. Symbols p, q, and r, indexed when needed, denote individual propositions. In(lD), 
Iti(Od)i and Iti(T(Id)) denote the sets of propositions, respectively in Id, Od, and T(Id)- We assume that 
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all propositions in Id, T, and Od are visible to all participant in a discussion about the relative validity of 
these artifacts. A participant having information in favor or against any proposition in Iti{Id), Iti{Od), and 
In(T(Ir>)) will voice that information. We evaluate the acceptability of the individual propositions in In(Io), 
In(0 D ), and In(T(I D )) in order to verify AC(I D ,T(I D ), D ): 

AC(I D ,T{I D ),0 D )ffiVp€ln(I D )Uln{0 D )Uln(T{I D )), AC(p) (2) 

The acceptability of a given proposition p is automatically verified in ACE via an algorithm that analyzes the 
information given in favor or against p, and captured via a language defined in the following section. 



4 Language 

We first present exemplified overview of the language f H4.ip . then provide a detailed definition of the language 



4.1 Overview of the Language 

All information relevant for the evaluation of acceptability is encoded into a directed labeled graph G, with the 
set of vertices V[G) and lines L(G), and the labeling functions Xy and Al for vertices and lines, respectively. 
Any one proposition p or a conjunction of propositions in any of In^Io), Iti(Od), and Iti(T(Id)) is captured 
by exactly one vertex v £ V(G). As all lines carry the same label VZ £ L(G), Al(1) = To, there is no need 
to write this label in graphs. There are four labels for vertices: Vi> £ V(G), Ay (v) £ {i, I, C, P}. G together 
with the labeling functions and the propositions forms the syntax of the language. Consider the following 
example for illustration. 

Suppose that the aim is to build a system that would deliver music on-demand: a user visits a website, 
chooses songs from a database, and can play them in the audio player on the website. The following is an 
important goal: 

(Ex.1) gx\ Generate revenue from the audio player. 

We refine it by the conjunction of the three goals 172, 93, and 174 below: 
(Ex.2) g2'. Display text ads in the audio player. 



(Ex.3) 
(Ex.4) 



93: Target text ads according to users' profiles. 
94: Maintain the player free to all users. 



We therefore have Id = 9i and Od = .92 A 93 A 54. The applied RE method is the standard AND-rcfincment 
of a goal [5]. We capture the application of AND-refincmcnt in the example via the graph shown in Ex.1. 

(Ex.5) 

I 

lr(i(si), {1(92), 1(93), 1(94)}) 
1(93) 



1(92) 



1(94) 



The refined goal g\ and the components 92, 93, 94 of its refinement are assigned the label i because of their 
role as the inputs and outputs to the application of an inference rule, denoted lT(i(<?i), {1(92), 1(93)1 1(94)})- 
The label i is assigned to an information vertex, which serves as the input and/or output to the application 
of an inference rule, corresponding to the label It- An inference rule vertex in G represents the application 
of some particular rule of deductive or ampliative inference to inputs in order to obtain the given outputs. 
An example of deductive inference is modus ponens. Inference or reasoning is ampliative when a conclusion 
is inferred, which includes information absent from the premises, from which the conclusion is inferred. 
Examples of rules of ampliative inference are induction by enumeration, reasoning with analogies, causal 
reasoning. Refinement, as any method is an inference rule, so that the application of AND-rcfinemcnt is 
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i(p 2 ) —> ±(pi) i(p 3 )-»i(pi) i(P4) -* i(pi) 

Figure 1: ACE graph capturing the application of the refinement method to the goal gi and the information offered 
in the discussion of that application of refinement. 



represented by lT(i(si), {1(32), 1(53), 1(54)}) in the graph. Any transformation T translates into at least 
one I vertex; it will equate to more vertices when we are not content with evaluating the acceptability of the 
application of the method as a whole (i.e., the black box approach), but are interested in evaluating in detail 
the acceptability of the various steps or other considerations called for in the application of the method. 
The meaning of each line is derived from the vertices it connects, and its direction. The line from i(<?i) to 
lT(i(<7i), {1(32), i(<?3)j 1(54)}) is understood as stating that the former is the input to the application of the 
given inference rule, It- 

An information vertex (i) can be involved in the application of a conflict (C) or of a preference rule (P). 
Suppose that a stakeholder indicates the following: 

(Ex.6) p±: Revenue can be generated by charging subscriptions to users 

A vertex labeled C indicates an application of a conflict rule, that is, the application of criteria giving rise to 
a conflict between two or more other vertices in the graph. Since it is clear that not all features of the player 
are free when a paid subscription is available, we add the conflict vertex Ci(i(pi), 1(34)) to the graph. 

(Ex.7) Ci: Subscription and advertising revenue models should not be combined on this 

system. 

Additional information can be found to elaborate on the subscription revenue model: 

(Ex.8) P2'- Part of the music database can be restricted, so that the player only plays 30 
seconds of some songs, until the user buys a subscription to listen full songs. 

(Ex.9) P3: According to competitors' services, some users are willing to pay to choose a 
different graphical layout for the online audio player; users can be allowed to choose 
among different graphical layouts and pay for each. 

(Ex.10) pi'. Two versions of the player can be offered, one with basic and free features, and 

another with advanced features requiring subscription. 

We choose to relate each of pi, P3, Pi via the modus ponens inference rule to p\. Say that a survey concludes 
that users strictly prefer a free music on-demand service to one based on subscription. Wc capture this 
strict preference by the preference vertex Pi(i(<74), i(pi)) and lines from 3.(174) to Pi(i((74), i(pi)), and from 
Pi(i(<74), i(pi)) to i(pi) in accordance to the direction of preference. A preference vertex represents the 
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application of a preference rule, that is, the application of criteria denning a strict preference order between 
the conditions described in two or more other vertices; we can write that rule as follows: 

(Ex.11) Pi: Users strictly prefer a free music on-demand service to one based on 

subscription. 

If the stakeholders agree that Pi(i(<74), i(pi)) resolves the conflict Ci(i(pi), i(ff4)), then an application of a 
conflict rule will be added, C 2 (Pi, {Cx, ifo)}), from P 1 (i(g 4 ), i(pi)) to Ci(i(pi), 1(54)) and i(p 2 ). 

(Ex.12) C 2 : Users' preference of free over subscription services should be satisfied. 

Figure [1] summarizes this discussion; applications of inference, conflict, and preference rules are given in the 
abbreviated form therein (i.e., Pi is written in place of Pi(i(<?4), i(pi))), and each application of the modus 
ponens inference rule is indexed differently as it takes different inputs, i.e.: 

• lMF,i({i(P2) -> i(pi),i(p2)},i(Pi)), 

• lMP,2({i(P3) -> i(pi),i(P3)}»i(Pi))) and 

• lMP,3({i(P4) -> i(p4)}, 

There are three constraints (l)-(3) imposed by the meaning of the To relationhship. (1) Any two vertices 
in G can be connected by at most one line. (2) No two information vertices can be connected; any information 
vertex must be connected to an inference, conflict, or preference vertex, for it is these vertices that establish 
the use to which the information vertices are put in G. (3) Any inference, conflict, or preference vertex 
must have at least one line that enters it, and another that exits it. There are no restrictions on the label 
of vertices to which an inference, conflict, or preference vertex can be connected. This makes the language 
rather versatile, as some forms of meta-reasoning can be captured. A preference may be given between other 
preferences (e.g., Pi — ► P 3 (Pi,P 2 ) — ► P2) to capture the priority among preferences. Inference rules can 
be compared in terms of preference (e.g., Ii — ► P(li,I 2 ) — ► I 2 ). Conflicts between preferences can be 
described, along with conflicts between conflicts, and conflicts between applications of inference rules. 

4.2 Definition of the Language 

We start from a terminology with four concepts. An ACE graphs captures the use of the instances of these 
concepts. 

Definition 4.1. ACE terminology. The ACE terminology is the quadruple: 

(Proposition, Inference rule, Conflict rule, Preference rule) (3) 
The concepts in the ACE terminology obtain informal meaning as follows. 

Definition 4.2. Proposition \1 6]/ . Any instance of Proposition is a shareable object of attitude (i.e., objects 
of beliefs, desires, intentions ) and is a primary bearer of truth and falsity. 

Remark 4.3. Instances of proposition are not restricted to a particular langagc or class(cs) of languagc(s). 
As usual then, a proposition can be a sentence in natural language, or a sentence in a predicate logic. 

Definition 4.4. Inference Rule. Any instance of Inference rule is a particular rule of deductive or amplia- 
tive inference that is applied to a nonempty set of propositions in order conclude another nonempty set of 
propositions. 

Example 4.5. We applied modus ponens in our earlier example (cf., £|4.1[) to conclude i(pi) from i(p 2 ) and 
i(j>2) — * The inference rule in that case is modus ponens. For an example of an ampliative inference 

rule, suppose that we have the following proposition: 

(Ex.13) Main competing service for on-demand music had less than a hundred thousand 
users in the first month of operation in a country with the same population. 

This may lead us to conclude the proposition below: 
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(Ex.14) The on-demand music service that is being built will not have more than a hundred 

thousand users in the first month of operation. 

To conclude this proposition, we applied reasoning by analogy, which is an ampliative inference rule. 

Definition 4.6. Conflict Rule. Any instance of Conflict rule are criteria indicating that a nonempty set 
of propositions opposes another nonempty set of propositions. 

Remark 4.7. Conflict rules may, but need not be project- and domain- independent. Logical inconsistency 
is an example of a domain- and project-independent rule of coflict. A project-dependent rule of conflict 
may indicate that conditions described by two propositions are alternative (hence, conflicting) not because 
they alone are logically inconsistent, but because together, they violate the conflict rule (e.g., meeting the 
conditions in both propositions together would overrun a deadline or budget). 

Definition 4.8. Preference Rule. Any instance of Preference rule are criteria indicating that the truth of 
a nonempty set of propositions is stritly preferred to the truth of another nonempty set of propositions. 

Remark 4.9. Any instance of Comparison rule equates to a binary relation on the universe of propositions. 
Let >-j symbolize a generic ith instance of Comparison rule. The intuitive reading of p >~ p' is "the truth of p 
is strictly better than the truth of v'" . A particular instance of Comparison rule, i.e., some >-j is not property 
neutral, whereby its properties are identified when collecting its applications to propositions. E.g., some >~i 
will be transitive, while others will not. What does it mean to say that an instance of Preference rule "are 
criteria"? Recall the earlier example (cf., ^4.1[) . where we captured by a strict preference the conclusion of 
a survey, which say that users strictly prefer a free music on-demand service to one based on subscription. 
This users' preference is a criterion that we use to compare propositions pertaining to the preference. This 
criterion gives us an instance of a Preference rule. Now, if we subsequently establish that users strictly prefer 
a subscription-based music service to a pcr-song payment (i.e., if the user listens ten songs, she pays ten 
times the unit price of a song), and that the free service is strictly preferred to a pcr-song payment, then our 
instance of Preference rule is transitive for the three given propositions. 

A discussion of the acceptability of the application of an re method involves the application of inference 
rules, conflict rules, and preference rules. Instances of Inference rule are are applied to premises in order to 
draw conclusions. Instances of Conflict rule are used to highlight opposition between the conditions described 
by propositions. Instances of Preference rule arc employed to indicate relative desirability of what the relevant 
propositions describe. It is therefore not the instances of inference, conflict, and preference rules that are 
captured for analysis in ACE, but the application of these instances to propositions. 

Definition 4.10. ACE Graph (G). An ACE graph G is a directed labeled graph: 

G=(V(G),L(G),V X ,L X ,L,X V ,X L ) (4) 

where: V{G) is a finite set of vertices (i.e., nodes, points); L{G) is a finite set of lines (i.e., edges); V\ is the 
set of labels for vertices; L\ is the set of labels for lines; l, the incidence function, is a function from L(G) 
to (V(G)) 2 ; Xv , the vertice labeling function, is a function from V(G) to V\, associating with each vertex in 
V(G) a label from V\; Xl, the line labeling function, is a function from L(G) to Xl that associates with each 
line in L(G) a label from XL- 
Example 4.11. Figure [T] shows an ACE graph. 
Definition 4.12. Labels for Vertices (V\). V\ = {i, I, C,P}. 

Remark 4.13. A vertex labeled i is called an information vertex, or simply information, and I, C, P are 
called, respectively, inference, conflict, and preference. 

Definition 4.14. Vertex Labeling Function (Xv ) and the meaning of vertex labels. For some vertex 
v G V(G): 

• Xv(v) = I iff v represents the application of an instance of Inference rule to specific propositions; 

• Xv(v) = C iff v represents the application of an instance of Conflict rule to specific propositions; 
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• Ay(v) = P iff v represents the application of an instance of Preference rule to specific propositions; and 

• Ay(v) = i iff v is a proposition that is neither the application of an instance of Inference rule, nor 
Conflict rule, nor Preference rule. 

Remark 4.15. The case Ay(v) = i is defined above in contrast to the other three cases. This is because any 
application of an instance of Inference rule is evidently a proposition: if we denote the inference rule with 
a predicate, the application of the inference rule gives us a predicate with no free variables, which thereby 
carries a truth value and is a proposition. Same applies for instances of Conflict rule and Preference rule: 
any application of a specific conflict or preference rule is a proposition. Not all instances of propositions are 
applications of inference, conflict, or preference rules. Consequently, if we have an instance of Proposition 
that is not itself the application of an inference, conflict, or preference rule to other propositions, then 
that proposition is called an information. By allowing an inference, conflict, or preference rule to apply to 
propositions, and as these applications are themselves propositions, we allow forms of mcta-rcasoning in ACE, 
which we mentioned earlier (cf., £|4.ip . 

Definition 4.16. Labels for Lines (L\). L\ = {To}. 

Definition 4.17. Line Labeling Function VZ € L(G), A^(Z) = To. 

Remark 4.18. The set of line labels is a singleton, so that all lines carry the same label and we chose above 
to omit this label from the visualization of the graphs ( i)4.ip . 

Definition 4.19. Lncidence Function (l). The incidence function obeys the following two constraints: 

1. for any ACE graph G and any two distinct vertices {v,v'} C V(G), if there is a line from v to v' in 
L(G), then there can be no line from v' to v in L(G), that is: 

VG, V{v, v'} C V{G), if l(v'v) ^ then i{vv') = (5) 

2. no line can connect two information vertices, that is: 

VG, V{v,v'} C V(G), p, G L(G) s.t. i{l) G {v'v,vv'} and X v (v) = X v (v') = i (6) 

Definitions of the ACE terminology together with the vertex labeling function provide the informal meaning 
of the vertices in an ACE graph. The meaning of a line in an ACE graph are determined from the vertices 
that the line connects and the direction of the line. 

Definition 4.20. Informal Meaning of the Lines. The meaning of the lines are given in TableUl as a 

function of the labels on vertices that the line connects and the direction of the line. 



5 Algorithms 

The graph in Figure Q] is a summary of the information offered in favor of and against the application of 
the AND-rcfmement method in Ex.1. Given such a graph, two tasks are relevant. The first, retrieval task 
is to search for particular subgraphs G in order to retrieve information that may be of relevance for further 
discussion among the participants and the evaluation of acceptability. The second, evaluation task is to 
determine if some specific application of an RE method is acceptable. We discuss the retrieval (^HHJ) and 
evaluation fi )5.2[) tasks in turn below. 

5.1 Retrieval 

An ACE graph is built by incrementally adding information and/or the applications of inference, conflict, and 
preference rules offered by the participants in the application of the RE methods. The subgraphs an ACE 
graph are retrieved to inform further debate and to act as the input to the evaluation of acceptability. 

Equation [2] indicates that the application of an RE method is acceptable if and only if each proposition 
describing the inputs (i.e., Iti(Id)), the application of the method to these inputs (i.e., In(T {I £>))), and the 
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Table 1: Informal meaning of the lines in an ACE graph. Columns indicate the label of the vertex, in which the line 
starts, while the corresponding column indicates the label of the vertex, in which the line ends. The intersection of a 
row and a column provide the informal meaning of the line. We use the following notational convention: in I e (Col, •), 
C e (Co/, •), and P e (Col, •), Col is replaced by the column head; e.g., at the intersection of the column i s and I e (Col, ■), 
Col = i s , so that I e (Col, •) = I e (i s , •)• 



Is 



Is 



Not allowed, because it 
is unclear why they are 
linked. 



I s (-,i e ) > i e : The in- 
ference rule application 
I s concludes the infor- 
mation i e . 



C B (-,i e ) — > U: The 
conflict rule application 
C s makes the informa- 
tion i e attacked by some 
other vertices. 



Ps(-,i e ) ► i e : The 

preference rule appli- 
cation P s makes the 
information i e strictly 
less preferred than some 
other vertices. 



I e (-,-) Not allowed, because an 
information vertex must 
be either a premise or 
a conclusion of an in- 
ference rule application, 
and is is not mentioned 
in I e (-,-)- 



Is(-,I e ) — > Ie(-,-): The 
inference rule application 
I e (-, ) is the conclusion 
of the inference rule ap- 
plication I s (-, ■). 



Cs(-,I e ) — > Ie(-,-_): The 
conflict rule application 
C s makes the inference 
rule application 
attacked by some other 
vertices. 



Ps(-,I e ) — > U{;-): The 
preference rule applica- 
tion Ps makes the in- 
ference rule application 
I e (-,-) strictly less pre- 
ferred than some other 
vertices. 



I e (CoZ, •) is > I e (is,-) : Infor- 
mation i s is a premise in 
the inference rule appli- 
cation I e . 



Is — > Ie(ls,-): Infer- 
ence rule application I s 
is a premise in the infer- 
ence rule application I e . 



C s > I e (C s ,-): Conflict 

rule application I s is a 
premise in the inference 
rule application I e . 



P s ► I c (Ps,-) : Prefer- 
ence rule application I s 
is a premise in the infer- 
ence rule application I e . 



C e (-,-) Not allowed, because an 
information vertex linked 
to a conflict rule appli- 
cation must be subjected 
to that conflict, and is is 
not mentioned in C e (-, ■). 



I s (-,C e ) ► C e (v): The 

conflict rule application 
C e (-, ) is the conclusion 
of the inference rule ap- 
plication I s (-, ■). 



C s (-,C e ) ► C e (•,•): The 

conflict rule application 
Cs makes the conflict 
rule application C e (-,-) 
attacked by some other 
vertices. 



Ps(-,C e ) — > Ce(;-): 
The preference rule ap- 
plication P s makes the 
conflict rule application 
C e (-,-) strictly less pre- 
ferred than some other 
vertices. 



C e (CoZ, •) is > C e (is,-) : Infor- 
mation i s attacks some 
other vertices by the con- 
flict rule application C e . 



Is > C e (ls, ): Infer- 
ence rule application I s 
attacks some other ver- 
tices by the conflict rule 
application C e . 



C s ► C e (C s ,-): Con- 
flict rule application I s 
attacks some other ver- 
tices by the conflict rule 
application C e . 



P s ► C c (Ps,-): Prefer- 
ence rule application I s 
attacks some other ver- 
tices by the conflict rule 
application C e . 



P e (-,-) Not allowed, because an 
information vertex linked 
to a preference rule appli- 
cation must be subjected 
to that preference, and 
is is not mentioned in 
Pe(-,0- 



Is(-,P e ) ► Pe(-,') : The 

preference rule applica- 
tion C e (-, •) is the conclu- 
sion of the inference rule 
application I s (-, ■). 



Cs(-,P e ) > Pe(-,-): The 

conflict rule application 
C s makes the preference 
rule application P e (-,) 
attacked by some other 
vertices. 



Ps(-,P e ) > Pe(-,-): The 

preference rule applica- 
tion P s makes the pref- 
erence rule application 
P e (-, •) strictly less pre- 
ferred than some other 
vertices. 



P e (CW, •) is > P e (is,-) : Prefer- 
ence rule application P e 
makes the information i e 
strictly preferred to some 
other vertices. 



Is > P e (ls,-) : Prefer- 
ence rule application P e 
makes the inference rule 
application I B strictly 
preferred to some other 
vertices. 



C s > P e (Cs,-): Prefer- 
ence rule application P e 
makes the conflict rule 
application C s strictly 
preferred to some other 
vertices. 



P s > P e (Ps,-) : Pref- 
erence rule application 
P e makes the prefer- 
ence rule application P s 
strictly preferred to some 
other vertices. 
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outputs is acceptable (i.e., Iti(Od))- To inform the participants of some specific proposition, or evaluate the 
acceptability of that proposition, we retrieve the vertex in the ACE graph that captures this proposition, 
along with all vertices relevant to the acceptability of that vertex. 

Definition 5.1. AC-Relevant vertex. A vertex v' is relevant to the acceptability of another vertex v in 
the same ace graph if and only if v' is directly or indirectly, in favor or against v. 

Example 5.2. Return to Figure [T] and consider the vertex 1(54). The vertex It is in favor of i(<74), as 3.(54) 
is a conclusion of the inference application It- Moreover, It is directly in favor of 3.(34) given that there is a 
line from It to i(<74). The vertex i(gi) is a premise to the inference application It, and is therefore directly 
in favor of It- Since i(<7i) is directly in favor of It, It is directly in favor of 3.(34), and there is no line from 
i(<7i) to i((?4), the vertex i(gi) is indirectly in favor of 1(54). It is clear that the conflict application Ci is 
against 3.(34), as the conflict application opposes i(pi) to 3.(34). The line 013.(34) makes Ci directly against 
i(.94)- 

There are two ways for a vertex v' to be directly against another vertex v: v' may make v attacked, or it 
may make v dominated. 

Definition 5.3. Attacked Vertex. A vertex v £ V(G) is attacked iff there is a line I G L(G) from a conflict 
vertex to v, i.e., 31 = v'v € L{G) s.t. Xv(v') = C. 

Remark 5.4. In a subgraph pattern v' — > C(v',v) — > v, we say that v' attacks v via the conflict rule 
application C(v',v); or cquivalently, v is the attacked vertex, v' is the attacker vertex, and C(v',v) is the 
attack. 

Example 5.5. In the attack C2, Pi is the attacker vertex, while and C2 and i(pi) the attacked vertices. In the 
attack Ci, 3.(34) is attacked by i(pi). 

Definition 5.6. Dominated Vertex. A vertex v € V(G) is dominated iff there is a line from a preference 
vertex to v, i.e., 31 = v'v € L{G) s.t. \y(y') = P. 

Remark 5.7. In a subgraph pattern v' — > P(i>', v) — ► v, we say that v' dominates v via the preference rule 
application P(v ,v), or equivalently, that v' is strictly better than v. 

Example 5.8. The preference rule application Pi(i(<74), i(f>i)) in Figure[T]indicates that 1(54) is strictly better 
than (i.e., dominates) i(pi). 

Both the conflict rule application that is an attack to a vertex, and the preference rule application making 
a vertex dominated, are directly against a vertex. While the attack on a vertex v is directly against v in 
v' — ► C(v' , v) — ► v, the attacker v' is indirectly related to v. Since v' attacks v via the conflict rule 
application, v' is indirectly against v. Similarly, v' in v' — ► P(v',v) — ► v is indirectly against v. It is clear 
that whether v is acceptable in v' — > C(v',v) — ► v will depend on whether C(v',v) is acceptable, which in 
turn depends on the acceptability of v': if the attacker is not acceptable, then the attack is irrelevant, and 
the attacked vertex is acceptable. Definition 15.11 and the examples above lead us to the following practical 
result. 

Proposition 5.9. If there is a path from a vertex v' to v in an ACE graph, then v' is relevant to the 
acceptability of v. 

Proof. Cf., Appendix EU □ 

Corollary 5.10. In any given ACE graph G, all vertices on all paths that end in v are relevant to the 
acceptability of v. 

The question at this point is if all vertices on all paths that end in v are the only vertices in G that are 
relevant to the acceptability of v. 

Proposition 5.11. In any given ACE graph, if there is no path from a v pr " ne to another vertex v, then v' is 
not relevant to the acceptability of v. 
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Figure 2: The discussion D[i((?4)] from the ACE graph in Figure [T] 



Proof. We prove Proposition 1 5 . 1 ll by contradiction. Suppose that v' is relevant to the acceptability of v, but 
that there is no path from v' to v. We know from Definition 15.11 that v' is relevant to the acceptability of 
v if and only if v' is directly or indirectly, in favor or against v. If there is no path from v' to v, then there 
is obviously no path from v' to any vertex that is on any path that ends in v. Equivalently, there is no line 
in L(G) that connects v' to any vertex on any path that ends in v. This leads to three observations: (i) v' 
is not a premise to an inference rule application concluding a vertex on a path that ends in v; (ii) v' does 
not attack a vertex on a path that ends in v; and (iii) v' does not dominate a vertex on a path that ends in 
v. This leads to a contradiction, as v' must stand in at least one of the said three relationships to v (and/or 
any vertex that is relevant to the acceptability of v) if it is to be relevant to the acceptability of v. □ 

Example 5.12. There are no paths between i(<?2) and i(<?3) in Figure [TJ so that neither of these vertices is 
relevant for the acceptability of the other. 

Remark 5.13. Observe that if v' is not relevant to the acceptability of v, then v may be relevant to the 
acceptability of v' . This occurs when there is a path from v to v' , but no path from v' to v. 

We are interested in retrieving all parts of a given ACE graph that arc sufficient to evaluate the acceptability 
of some specific vertex. Corollarv l5 . 101 and Proposition lS. 1 ll indicate that we must retrieve all distinct paths in 
G that end in v, in order to evaluate the acceptability of v. This leads us to introduce the notion of discussion, 
which, for a given vertex v £ V(G) carries all parts of the graph G that are necessary to determine whether 



Definition 5.14. Discussion of v (D[v\). The discussion of a vertex v in an ACE graph G is the subgraph 
of G, which contains exactly all distinct paths in G that end in v. 

Example 5.15. Figure [5] shows the discussion of 1(54), i.e., D[l{gi)\. This discussion contains all distinct 
paths from the ACE graph in Figure [T] that end in i(<?4). 

The acceptability of a vertex v in an ACE graph is evaluated by the analysis of the discussion of v, i.e., 
D[v}. To perform the evaluation of acceptability of a vertex v £ V(G) in an ACE graph G, we must first 
retrieve D[v] from a given G. Algorithm [1] retrieves retrieves a discussion of the given vertex. 

Proposition 5.16. Algorithm]]] applied to a vertex v in an ACE graph (i) does not loop indefinetly, (ii) 
returns all direct and indirect vertices in favor of or against the starting vertex v (i.e., returns the discussion 
of v, D[v]), and (iii) has the running time in 0(\V(D[v])\ + |L(D[w])|). 



AC(u). 
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Algorithm 1 Find Discussion 

Require: A nonempty ACE graph G, a starting vertex First E V(G); 
Ensure: A nonempty graph D[First], which is a subgraph of G; 

procedure FindDiscussion(G, First) 

Empty the queue Q; V{D[First]) <- 0; L(D[First]) <- 
Add First to Q 
while Q is not empty do 
for each vertex v in Q do 
Add u to V(D[First]) 
for each v' £ V(G) s.t. 3u'« E L(G) do 
if v'v i L(D[Firsi\) then 
Add v'v to L(D [First]) 
end if 

if v' £ V{D[First]) then 
Add v' to V{D[First]) 
Add u' to Q 
end if 
end for 

Delete v from Q 
end for 
end while 
end procedure 



Proof. CI, Appendix [O □ 

Algorithm Q] is an adaptation of the usual breadth first search algorithm (e.g., [13J. When applied to 
an ACE graph G, Algorithm [1] enqueues the starting vertex First and visits it. It then enqueues all vertices 
on lines incoming to the visited node, and dequeues the visited starting node. All vertices in the queue are 
visited in the same manner and are added to the discussion D[First\. The discussion also receives all lines 
from G connecting the vertices in that discussion. 

Definition 5.17. Subdiscussion. D[v'] is a subdiscussion of D[v] if and only ifV(D[v']) C V(D[v]) and 
L(D[v'}) C L(D[v]). 

Proposition 5.18. If v' E D[v], then D[v'] is a subdiscussion of D[v}. 

Proof. We give a trivial proof by contradiction. A discussion D[v E V^(G)] contains, by Definition 15 . 141 all 
distinct paths in G that end in v. Suppose that there is a vertex v' E V(D[v}) such that V(D[v'])nV(D[v}) ^ 
V(D[v'}). There is thus a vertex v" that is on a path that ends in v', but there is no path from v" to v. This 
is a contradiction: if there is a path from v" to v' , and a path from v' to v, there there must be a path from 
v" tov'. □ 

Proposition l5.18l is a useful result, since retrieving D[v] also retrieves the discussions of all vertices in V r (£'[u]), 
that is, all subdiscussions of D[v]. 

5.2 Evaluation 

The acceptability of the vertex v is evaluated by traversing and computing the labels on vertices in the 
discussion of v, D[v\. The computed label of a vertex is a secondary label, and is different from that assigned 
by Ay. The computed label indicates whether a vertex is acceptable. We first give an informal overview below, 
of how a discussion is traversed and labels computed ( t)5.2.ip . then provide the details of the acceptability 
evaluation algorithm ( £|5.2.2|) . 
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5.2.1 Overview of Evaluation 



The computed label of any vertex in D[v] is either A for accepted, AD for accepted and dominated, or R for 
rejected. We illustrate the computation of labels by simple examples first, then go on to label the discussion 
-D[i(<74)] obtained from the graph in Figure [TJ and finally give an informal outline of the algorithm that 
computes the labels of any discussion. 

Consider an ACE graph G with only a single vertex V(G) = {v} and L(G) = 0, so that D[v] = G. 
Being alone in D[v], v is neither attacked nor dominated; we therefore say that v is acceptable, and label it 
A, denoted a^ 1 - Consider now a graph G" with three vertices and two lines between them. To compute the 
labels in G" , we need to know the direction of the lines and the primary labels on the vertices: 

• if G" is ix — ► l(ii, 12) — ► 12, then all vertices are neither attacked nor dominated, and they all take 
the label A, i.e., A ii — ► A l(ii,i2) — > A±2', 

• if G" is ii — > C(ii, i 2 ) — > iaj then ±2 is attacked; we see that ii and C are not attacked, and conclude 
that i 2 is rejected: A ii — > AC(ii,i 2 ) — > r±2] 

• if G" is ii — ► P(ii,i2) — ► i2, then i 2 is dominated. To be dominated alone is not enough for 
rejection, so that ±2 is accepted and dominated, that is a^i — > AP(ii, 12) — ► ADi2- 

These three cases illustrate the first important principle used in computing the labels of a discussion: the 
label on a vertex v depends on the labels of all vertices V\, . . . ,v n adjacent to v by lines viv,V2V, . . . ,v n v. 
This alone is not enough, as we must know how the labels interact - consider the hypothetical discussion 
D[ii] in Ex.15. 

(Ex.15) 

Ai-4 Ai-2 — >■ rI({12, 13}, ii) — Rll 

\ ^ 

A C(i4, — ^ R i3 



The inference I({i2, 13}, ii) uses two inputs, one accepted i2 and another i3, which is attacked by the 
accccptcd i4 (hence the rejection of 13). The inference itself cannot be accepted, since one of its inputs 
is rejected. Given that the application of the inference rule is rejected, the conclusion of the inference, ii, 
must be rejected as well. Ex.15 illustrates the choice that the label R has priority over A. We choose to be 
cautious in computing the labels, meaning that R has priority over AD and A, and AD has priority over A. 
In addition to this second principle employed in the computation of the labels, we have a third and final one, 
illustrated via Ex.16. 



(Ex.16) 



Al4 A^2 *■ Al(i2, il) — *" A 1 ! 

\ ^ 
A Ci(i 4! C 2 ) R C 2 (i3,l) ■< Ai3 



Suppose that no computed labels are given in Ex.16. We see immediately that i4, i3 and i2 should be 
accepted as they are not attacked, along with Ci(i4,C2). C2(i3, 1) must then be rejected, as it is attacked 
via Ci(i4,C2). Observe then that I(i 2 ,ii) has two incoming lines, one from the accepted ±2 and another 
from the rejected conflict C2(i3, 1). While it is true that R has priority over A, we conclude that I(i2, ii) is 
accepted, because the rejected conflict is not an input to the inference I(i2, ii)- We have noted earlier that 
the meaning of a line in an ACE graph is determined from the labels that Ay assigns to the vertices connected 
by the line. The conclusion that l(i 2 , ii) is accepted cannot be reached without determining the meaning of 
each line ending in I(i2, ii). By reading these lines, we see that I(i2 5 ii) does not take the conflict C 2 (i3, 1) 
as its input, but that this conflict attacks I(i2, ii)- If the conflict is accepted, I(i2, ii) should be rejected; 
however, the conflict is rejected, so that I(i2, ii) is accepted. More generally, the third principle we use in 
computing the label on a vertex v is that the meaning of each line that ends in v must be determined. This 
leads us to define a number of deduction rules for labels, which account for the meaning of the relevant line. 
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To see how these rules are used, consider again the vertex I(i2, ii). Since it has lines incoming from two 
different vertices, we use the following two label deduction rules\j 

• from ai — ► conclude that the inference I(i, •) should be acccepted (where ai — ► l(ij') 
means that the inference l(i, ■) uses the accepted i as its input and concludes something else, i.e., "•"); 
and 

• from rC(-, I) — ► l(-, •), conclude that the inference l(-, •) should be accepted (where rC(-, I) — ► l(-, •) 
means that the inference l(-, •) is attacked by the rejected conflict C(-, I)). 

The application of two rules, as above, gives us two labels, both A; it is thus clear that l(±2, ii) will bear 
the label A. More generally, if v has n incoming lines v±v, V2V, . . . , v n v, then we will apply n rules, selected 
depending on the label of each m G {v\, i>2, ■ ■ ■ , v n }. This will result in n labels. The one label that we will 
assign to v will be that of the n labels, which has the priority over others, according to the principle of how 
the labels interact, and given above. E.g., if we have the set of n labels, in which there is at least one label R, 
we will conclude rw; if each label is A, then av; if there are no R labels, but only A and AD labels, then ad« • 
Seventy two label deduction rules cover all cases allowed by the meaning of the To line in any ACE graph. 
We provide their definitions later on (cf., §5.2. 2p . 

We now ask if i(<74) is acceptable. The answer can be given once we compute the labels on the discussion 
-D[i(<?4)]. We find the discussion D[i(<74)] via Algorithm Q] and then proceed as follows: 

1. If there arc preferences in the discussion that arc transitive, the steps below are performed on the 
transitive closure of these transitive preferences on the discussion of choice. Regardless of whether Pi 
is transitive, the transitive closure of Pi on D[i(g4)] is the same as D[±(g4)]. 

2. We now need to find a topological sort of the strongly connected components of the discussion -D[i(<?4)]. 
A discussion can contain cycles, which is why we must first identify the strongly connected componcntsjj 
Figure [3] shows the discussion £> [3.(174)], where each strongly connected component is delimited by a 
rectangle. The largest strongly connected component contains cycles, while the others contain no cycles. 
Once we have a topological components, we need their topological sort. It is well known that contracting 
each strongly connected component in a directed graph gives a directed acyclic graph, where each vertex 
is a contracted strongly connected component. A topological sort of that directed acyclic graph is a 

1 As a notational convention, we write "■" for the parameter that is not important for the application of the given rule. 
2 As usual, a strongly connected component is a graph, in which there is a path from any vertex to any other vertex. 
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linear ordering of its vertices, in which a vertex comes before all vertices, to which it has outcoming 
lines. To see why we need a topological sort of the strongly connected components, consider the problem 
of labeling Imp,i (same applies to the problem of labeling Imp,2 and 1mp,z)'- the label of Imps depends 
on the labels of I(p2) and ife) — * i(Pi)- Consequently, we must label I(jp2) and i(p2) ~~ * i(Pi) before 
we label Imps- In a topological sort, Imps comes after both i(j>2) and i(j>2) —> i(.Pi)- A topological 
sort therefore gives the order, in which the strongly connected components should be labeled. 

3. Given a topological sort of the strongly connected components of the discussion D[i(g4)}, we label all 
elements in the sort that have no incoming lines. We consequently label as accepted the following 
vertices: A±(gi), a±(p2), Aife), Ai(p4), a(i(P2) a(i(P3) -> i(Pi))j and a(i(P4) -> i(Pi))- 

Once these are labeled, the next elements in the sort are the three applications of modus ponens and 
It- They are not attacked and their inputs are accepted, so that aImpsi aImp,2, &Imp,3, and Air- 
Labeling i(pi) is more difficult and requires a different strategy. This is because i(pi) lies on at least 
one simple cycled To label a strongly connected component with cycles, we proceed as follows: 

(a) The count, say C of simple cycles in the strongly connected component is computed. C = 3 in 
the strongly connected component containing i(pi). 

(b) We add an empty sequence of labels on each vertex in the strongly connected component, and add 
the label A to the sequence of each vertex. 

(c) We choose a vertex according to a specific heuristic (namely, we take the last added vertex in 
the strongly conncted component, as discussed in detail later on - cf., iJ5.2.2[) and call it the 
First vertex. In D[l(g4)], Pi is that vertex. In doing so, we in fact merely hypothesize that 
Pi is accepted. To understand intuitively what happens next, suppose that there are C walkers 
stationed at Pi. Each walker obeys the following: (i) it takes equal time to traverse a vertex; (ii) it 
can only go forward (i.e., over lines that start in a vertex); and (iii) no two walkers will start from 
First and return to First along the exact same path. In the strongly connected component with 
i(pi), we place three walkers at the vertex Pi and send them along the lines outgoing from Pi. 
After the first step, two walkers will reach C2 and one will reach i(pi). Once they reach a vertex, 
they compute the label on that vertex by using the label deduction rules we explained earlier. 
The computed label is appended to the sequence of labels on the vertex. For (a)Q2, we append 
the sequence of labels with A, and obtain (a.a)^2- Since all three applications of modus ponens 
are accepted and (a)Pij we get (A,AD)i(Pi)- After the second step, two walkers are at Ci, and the 
third is at i(pi), so that (a,a,r,r)Ci and (A,AD,R)i(Pi)- The fourth step results in (A,A)i(ff4)- After 
the fourth step, two walkers arrive simultaneously at the first vertex Pi. However, the first vertex 
obtains its second label (i.e., (a)Pi becomes (a.a)Pi) only after the slowest walker, i.e., the one 
traversing the longest path back to the first vertex, arrives at that vertex0 

The stopping criterion for the walkers is as follows. If the last two labels in the sequence of labels on 
the first vertex are identical, the walkers are not sent to traverse the strongly connected component 
any further. This is the case in the example, where (a, a) Pi- The last label in the sequence of labels on 
any vertex is the label that indicates the acceptability of that vertex: if A, the vertex is acceptable, if 
AD, the vertex is acceptable and dominated, if R, the vertex is not acceptable. In case the first two 
labels in the sequence of the first vertex are not identical, the walkers will be sent out in the same way 
as described above, until the first vertex has four labels. When the first vertex has four labels and its 
last two labels are not identical, then the given discussion is inconclusive with regards to acceptability: 
more vertices need to be added (i.e., the discussion should continue) before the discussion is evaluated 
again. 

The sequence of steps exemplified above is the informal outline of the algorithm that labels any discussion. 
The algorithm, called EvaluateDiscussion is formally introduced and discussed below. 

3 As usual, a simple cycle is a cycle that passes once through all vertices except its starting vertex, which the cycle passes 
twice (as the cycle starts and ends in that vertex). 

4 Observe that the number of labels in the sequence of labels of a vertex, in a strongly connected component with cycles, 
equals 1 plus the number of times a walker traversed that vertex. This is valid for all vertices other than the First vertex. 
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(A)i(si) 
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(A) It 




(A) (i(P2) -> i(pi)) (a> (i(Ps) -+ i(pi)) (A) (i(P4) ~> i(pi)) 
Figure 4: Result of evaluating the discussion D[i(<74)] for acceptability. 

5.2.2 Definition of Evaluation 

We now present the algorithm that was informally outlined above. We start by defining the three computed 
labels and the rules governing their interaction. 

Definition 5.19. C-label. A computed label, or c-label, on any vertex v in an ACE graph G is either A for 
accepted (equivalently, acceptable), AD for accepted and dominated (i.e., acceptable and dominated), or R for 
rejected (i.e., not acceptable). 

Remark 5.20. An A c-label on v indicates that v is acceptable, that is, AC(v) holds. If v carries the c-label 
R, then AC(u) does not hold. The c-label AD gives two indications: one is that AC(v) holds, while the D 
in AD says that there are acceptable vertices in G that are strictly more preferred to v. 

The c-label of a vertex v S V(G) is computed by taking into account the c-labels on vertices v\, V2, ■ • • , v n 
such that 3{viv, v^V, . . . , v n v} C L(G). We call each of Vi, V2, ■ ■ ■ , V n an in-adjacent vertex. The c-labels on 
the various in-adjacent vertices can be different, so that it becomes necessary to know how to combine them 
when computing the c-label on v. Consider the graph pattern below. 

(Ex.17) 

vi v 2 ■■■ v„ 




Suppose that vertices v± to v n -2 are all accepted, v n -i is accepted and dominated, and v n is rejected. To 
compute the c-label on v, we obviously need to know the labels assigned by Xy to each vertex v, v\, . . . , v n . 
E.g., if Xv{vi) = C, then the c-label AD will be propagated from V\ to v. We therefore require the rules for 
how c-labels are sent between vertices in an ACE graphs, depending on the labels of vertices (i.e., i, I, C, and 
P) and the direction of the To line between a given pair of vertices. 

Remark 5.21. The rules for the propagation of c-labels across lines are used by the evaluation algorithm 
when it traverses a vertex. Since the application of such rules will propagate as many c-labels on v as there 
are in-adjacent vertices to v, we associate a set, called t-set to a vertex. Each member of a t-set if a c-label. 
If v has n in-adjacent vertices, the t-set of v will receive n members each time the evaluation algorithm 
traverses v. Because the evaluation algorithm mey traverse a vertex more than once, we also add a sequence 
of c-labels, called c-sequence on each vertex in an ACE graph. The evaluation algorithm appends a c-label 
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to the c-scquencc of a vertex, by inferring that c-labcl from the c-labels in the t-set of that vertex. Each 
member of a c-sequence is a c-label. The use of both the t-set and the c-sequence of a vertex will be clarified 
below. When it is relevant to make explicit the c-sequence of v, we write /...)V. When it is relevant to make 
the t-set of v explicit, we write {'"*v. 

Definition 5.22. propagateLabel Function. propagateLabel : V(G) x V(G) — ► {A,AD,R}. For a line 
v'v G L(G) in an ACE graph, such that v' has a c-label, the propagateLabel function returns a c-label for the 
vertex v, based on Ay(v') and the direction of the line from v' to v. Tabled completely defines the function 
propagateLabels. 

Remark 5.23. Table [5] has a similar structure as Table [JJ For each case in Table [TJ Table [3] studies three 
cases, one per allowed label. E.g., for the case I s (-, i e ) — ► i e (second column, first row in Table [TJ, Table 
Ogives three rules: (i) if I s (-, i e ) has the c-label A, then i e obtains the c-label A (rule 17 in Table [3J; (ii) 
if I s (-, i e ) has the c-label AD, then i e obtains A (rule 18 in Table[2J; and (iii) if I s (-, i e ) carries R, then i e 
obtains R (rule 19 in Table HJ. 

Example 5.24. In Figure [2] 

• propagateLabel(b±(gi) , It) = A; 

• propagateLabel(blT, i(gi)) = A; 

• propagateLabel(bCi, i(<?4)) = R; and so on. 

To compute the c-labcl on a vertex v, which has in-adjacent vertices v\, ...,v n , we propagate a c-label 
from each of v\, . . . , v n . We consequently end up with n c-labcls in the t-set of v, so that it becomes necessary 
to determine which of the n c-labels to infer from the t-set of v. We do so by applying the inference rules for 
multiple labels. 

Definition 5.25. Inference Rules for Multiple C-Labels. When there are n alternative c-labels for a 
vertex v, then the c-vertex on v is determined by the application of the following rules: 

1. Rejection R overrules acceptance A: from R and A, conclude R. 

2. Rejection R overrules dominated acceptance AD: from R and AD, conclude R. 

3. Dominated acceptance AD overrules acceptance A: from AD and A, conclude AD. 

Example 5.26. In Figure [2j suppose that both It and Ci carry the c-label A. To determine the c-label 
on i(<74), we call the function propagateLabel on both vertices that are in-adjacent to i(<?4). We thus have 
propagateLabel{mlT , 1(34)) = A and propagateLabel^Ci, i(<?4)) = R- We thus have ^ A ' R ^i(gi). We follow the 
first rule in Definition 1 5 . 251 and conclude that the c-label on i(<?4) is R. We append the c-sequence of v with 
the c-label inferred from the t-set (and empty the t-set), so that 1 r\ 1(34)- 

We combine the propagateLabel function (cf., Definition [5T22J and the inference rules for multiple labels in 
Algorithm^ The procedure ComputeLabel is called by the evaluation algorithm whenever that algorithm 
visits a vertex in the discussion that is being labeled. 

Algorithm [2] is given a vertex Vi from a discussion D[v\. The algorithm first empties the t-set of Vi (cf., 
Line 2 in Algorithm [2J . The for each loop then considers all in- adjacent vertices of Vi in the dicussion 
D[v] (cf., Lines 3-9). For each considered vertex v', the propagateLabel function is called: if its result is 
an error, then the line v'vi is not one allowed by the meaning of the To link - the algorithm stops and 
reports the error. If propagateLabels(v' ,Vi) returns a c-labcl instead of an error, that c-labcl is added to the 
t-set of Vi. The for each loop finishes after it has considered all vertices in D[v] that arc in-adjacent to 
Let inDegree(vi,G) = \{v' \ 3v'vi £ L(G)}\, so that inDegree(vi, D[v]) is the number of vertices in-adjacent 
to Vi in D[v]. Observe that the cardinality of the t-set of Vi equals inDegree{vi, D[v\) . Once the t-set has 
inDegree(vi, D[v]) elements, Dcfinition l5.25l is applied via the last if block (cf., Lines 10-16) to determine the 
overruling c-label in the t-set. 

Proposition 5.27. Algorithm^ applied to a vertex v% in a discussion D[v] (i) does not loop indefinetly, (ii) 
returns the overruling c-label among the c-labels propagated from all in-adjacent vertices to v% in D[v], and 
(iii) has the running time in 0(inDegree(vi, D[v])). 
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Table 2: Complete definition of the propagateLabel function. To simplify the presentation below, the notation [/ ..,A)i, •)] ^ [A] ^ s an abbreviation of 
propagateLabel(^^^i, I(i, •)) = A, where A is the c-label added to the t-set of l(i, •). As in Table [1] we write l(o, b) to indicate that a is used to infer b 
by the application of I; P(a, b) indicates that a attacks b by the conflict rule application P; P(a, b) indicates that a is strictly better than 6 according to the 
preference rule application P. An additional convention is that if we write propagateLabel(( jA \i, l(i, •)), then the labeled i is the parameter i in l(i, •); if we 
write propagateLabel{/ „^\x, I) then the labeled i is not a parameter in I (i.e., the parameters of I are some vertices other than the given information vertex i). 



[ ( ... >A) i,C(i,-)]=HA] (10) [ ( ... iA) i,P(i,.)]=HA] (13) 

[(..,AD)i,C(i,-)]=MA] (11) [<...,AD)i,P(i,-)]=MA] (14) 

[<...,R)i,C(i,-)]=>[R] (12) [ ( ,.. >R> i,P(i,.)]=HR] (15) 



In any case other than (8)- 
(79), getLabel returns error. 



[ ( ..., A) i,l(i,-)]^[A] (7) 
[ ( ..„ AD) i,l(i,.)]=HA] (8) 
[ ( ... iR> i,l(i,.)]=HR] (9) 



[ ( ..., A) l(.,i),i]=HA] (16) 
[ ( ...,AD>I(-.i).i] => [A] (17) 
[(...,R>I(-,l),i]=MR] (18) 



[ ( ..., A) I(-,I'),I']^[A] (19) 

[ ( ..„ A) I,I'(I,.)]^[A] (20) 

[ ( ... >AD) I(-,I'),I']^[A] (21) 

[ ( ..„ AD) I,I'(I,-)]^[A] (22) 

[ ( ... iR) l(-,l'),l']^[R] (23) 

[ ( ..., R> I,I'(I,-)]^[R] (24) 



[<...,A>I(->C),C] =>• [A] (25) 

[<...,A)I.O(I,0]=>-[A] (26) 

[<...,AD>I(',C),C]^[A] (27) 

[(...,AD)I,C(I,-)]=*-[A] (28) 

[ ( ..., R> I(-,C),C]^[R] (29) 

[<„.,r>I.C(I, •)]=>•[«] (30) 





..., A) I(-,P),P] => [A] 


(31) 




..., A) I,P(I,-)] => [A] 


(32) 


[(. 


„ AD) I(-,P),P] => [A] 


(33) 


[(. 


„ AD) I,P(I,-)] [A] 


(34) 




...,R>I(-,P),P] => [R] 


(35) 




.„ >r> i,p(i,.)] => [R] 


(36) 



[ ( ..., A> C(-,i),i]=HR] (37) 
[ ( ... jAD) C(-,i),i]^[R] (38) 
[ ( ... iR> C(-,i),i]^[A] (39) 



[(...,A)C(', I), I] => [R] (40) 

[(...,A)C, l(C, ■)] => [A] (41) 

[ ( ..„ AD) C(-,I),I]^[R] (42) 

[(..., AD) C,I(C,-)] => [A] (43) 

[<.... R> C(-,I),I] => [A] (44) 

[(...,R)C, I(C, ■)] => [R] (45) 



[ ( ..., A) C(.,C'),C']^[R] (46) 

[<...,A)C,C(C, •)]=>■ [A] (47) 

[ ( ...,ad>C(-,C'),C] => [R] (48) 

[<...,AD)C,C'(C,-)]^[A] (49) 

[ ( ..., R) C(-,C'),C] => [A] (50) 

[<...,R)C, C'(C, •)] => [R] (51) 





...,A)C(-,P),P] => [R] 


(52) 




...,A)C,P(C,.)] => [A] 


(53) 


[(. 


.,AD)C(-,P),P] [R] 


(54) 


[(. 


„ AD) C,P(C,-)] => [A] 


(55) 




...,r>C(-,P),P] => [A] 


(56) 




...,r>c,p(c,-)] => [R] 


(57) 



[ ( ...,A)P(-,i),i]^[AD] (58) 
[ ( ..., AD) P(-,i),i]^[AD] (59) 
[ { ...,R>P(-,i),i]=>-[A] (60) 



[ ( ... iA) P(.,l),l]=HAD] (61) 

[ ( ... iA) P,l(P,.)]^[A] (62) 

[ ( ..., AD) P(.,I),I]^[AD] (63) 

[(..., AD> P,I(P,-)] => [A] (64) 

[ ( ... iR) P(-,l),I]^[A] (65) 

[(...,R)P,I(P,0]=>-[R] (66) 



[ ( ...,a>P(-,C),C] => [AD] (67) 

[<...,A)P,C(P,0] => [A] (68) 

[<...,AD)P('> C), C] => [AD] (69) 

[<...,AD)P,C(P,-)]^[A] (70) 

[<...,R)P('i C)j C] => [A] (71) 

[ ( ... jR) P,C(P,.)]^[R] (72) 



[ ( ..., A) P(-,P'),P']^[AD] (73) 

[ ( ... >A) P,P'(P,.)]^[A] (74) 

[<...,AD)P('>P')>P'] =^ [AD] (75) 

[<...,AD>P,P'(P,-)]=HA] (76) 

[ ( ..., R) P(-,P'),P']^[A] (77) 

[<...,r>P,p'(P,-)]=S>[R] (78) 



Algorithm 2 Compute a C-Label 



Require: A discussion D[v] and a vertex vi 6 y(D[v]); 
Ensure: A c- label for v^; 



l: procedure ComputeLabel^, D[v]) 

Initialize: 
2: Empty the t-set of u; 

Fill the t-set of in: 
3: for each Bv'vi £ L(D[v]) do 

Apply Definition ] 5. 22\ to propagate a c-label to Vi from the vertex v' : 
4: if propagateLabel{v' ,Vi) is not an error then 

5: Add the result of propagateLabel(v' ,Vi) to the t-set of Vi 

6: else 

7: Stop and return error: disallowed graph structure encountered. 

8: end if 

9: end for 

Apply Definition 1 5. 25\ to infer the overruling label in the t-set of Vi : 
10: if there is at least one R in the t-set of Vi then 
11: Stop and return R. 

12: else if there is at least one AD in the t-set of Vi then 
13: Stop and return AD. 

14: else 

15: Stop and return A. 

16: end if 

17: end procedure 



Proof. Trivial; cf., Appendix I A. 3 1 □ 

The ComputeLabel procedure is called within the evaluation algorithm, of which an informal outline 
was given earlier (cf., §5.2.ip . Three steps were identified: (1) the algorithm builds the transitive closure 
of the transitive preference rules, the applications of which appear in the discussion being evaluated; (2) 
the algorithm builds a topological sort of the strongly connected components of the transitive closure of the 
discussion; and (3) the algorithm labels the strongly connected components, in the order of their topological 
sort. These three steps are performed in the given sequence by Algorithm [3j called EvaluateDiscussion. 
Given a discussion D[v], EvaluateDiscussion will compute, if they exist, stable c-labels on each vertex in 
the discussion. Errors will be returned if the c-labels are not stable, or if the algorithm encounters a line that 
violates the meaning of lines in an ACE graph, as established in Definition 14.201 

Definition 5.28. Stable C-Label. The mth c-label in the c-sequence of a vertex v is a stable label for that 
vertex if and only if for any integer i > 0, any (m + i)th c-label, computed at the (m + i)th traversal of v, 
equals the mth c-label in the c-sequence of v. 

If the algorithm finds stable c-labels, we can immediately answer the question of whether each vertex in 
the discussion is acceptable. If EvaluateDiscussion returns an error, then the discussion must be revised: 
new vertices may need to be added if stable labels are absent, while all lines violating the meaning of the 
lines in an ACE graphs should be removed. 

Proposition 5.29. Agorithm applied to a discusssion D[v] (i) does not loop indefinetly, (ii) returns 
stable c-labels for all vertices in D[v] if they exist, an error otherwise, and (Hi) has the running time in 
0{C{D c [v])(\L(D c [v])\ +2\V(D c [v})\)), where C(D c [v}) is the number of simple cycles in D c [v] and D c [v] is 
the transitive closure of the transitive preference rules in D[v] on D[v]. 

Proof. Cf., Appendix I A. 5 1 □ 

EvaluateDiscussion applied to D[v] starts by building the transitive closure on transitive preference 
rule applications in D[v] to obtain Z? c [w]. P T is a set of sets; each element in P T is a set of preference 



20 



rule applications that are transitive. Figure 5(a) gives a hypothetical discussion £>[ii], where Ci,i, Ci,2, 



and Ci,3 are assumed to be three applications of the same transitive preference rule Ci. Figure 5(b) shows 



the discussion D c [ii], obtained by computing the transitive closure of Ci on the discussion -D[ii]. -D c [ii] 
is the result of BuiLDTRANSiTiVECLOSURE(£)[ii] , P T ), where P T has only one element, which is the set 
{P1.1, P1.2, Pi,3j- The procedure BuildTransitiveClosure is described in detail in Appendix IA.4I 



t 

P1.3 

t 



c 2 



- 12 

I 

Pl.l 

I 

3 1,2 -< 13 



(a) 




Figure 5: Figure 5(a) shows a hypothetical discussion, in which all preference rule applications are different appli- 
cations P1.1, Pi, 2, Pi, 3 of the same comparison rule Pi and Pi is assumed to be transitive. Figure 5(b) shows the same 



discussion complex smallest justification updated for the transitive closure of Pi on the discussion in Figure 5(a) 



The next step (cf., Line 4 in Algorithm[3]) is to find all strongly connected compontens in D c [v]. -D c [ii] in 
Figure[5]has a single strongly connected component, while D c [±(g4)] in Figure[2]has twelve strongly connected 
components, as illustrated in Figure[31 We do not discuss the detail of EnumerateSCC, as it amounts to 
Tarjan's strongly connected components algorithm [19j . or an improved variant thereof (cf., e.g., |18|). 

The strongly connected components of a D c [v] returned by ENUMERATES CC(D c [v}) are recorded in the 
set C. Each element a G C is a strongly connected component of -D c [w], and thereby a subgraph of Z? c [u]. The 
c-labcls arc computed by traversing each strongly connected component separately. Since the labels on the 
vertices V(ci) in a strongly connected component a may depend on the labels on vertices V(cj) of another 
strongly connected component Cj, an order must be established, in which the strongly connected comoponcnts 
should be traversed to compute c-labels on their vertices. It is well-known that if we contract each strongly 
connected component in a directed graph down to a single vertex, the result is a directed acyclic graph. The 
procedure ContractSCC takes a D c [v] and the set of its strongly connected components, and returns a 
directed acyclic graph Dc- Each vertex Wi € V(Vc) represents exactly one strongly connected component 
in C. ContractSCC starts by adding as many vertices Wi to V(Dq) as there are strongly connected 
components in C. The first for each loop then considers each strongly connected component q G C, and 
defines the function standsFor : V(Dc) — > C. The standsFor function associates to each Wi € V(Dc) a 
strongly connected component c; £ C that Wi represents; one can understand a vertex Wi as being the result of 
shrinking Cj down to a single vertex. We shall say that the function standsFor returns the strongly connected 
component in C that is represented by a given vertex in Dc- After the current Ci is associated to a Wi in Line 
13, the for each loop in Lines 15-23 considers for each Wi £ V(Dc), all other wj ^ Wi in order to check if 
there is a line in Z) c [i;] from a vertex in V (standsFor(wi)) (i.e., V(ci)) to a vertex in V (stands For(vjj)) (i.e., 
Cj). If such a line exists, a line between Wi and Wj is added to L(Dc)- ContractSCC thereby returns a 
graph, in which each vertex stands for exactly one strongly connected component of D c [w], and in which any 
two distinct vertices and Wj are connected by a line WiWj if and only if there is a line from a vertex in 
V (standsFor(wi)) to a vertex in V (stands Foriutj)) . 

Given a directed acyclic graph Dq and the function standsFor, both from ContractSCC(£> c [u], C), we 
can determine the order, in which to traverse the strongly connected components of _D c [t>]. A topological 
order of the vertices in Dc is a sequence of vertices, in which (i) the vertices without incoming lines occupy 
the first places, (ii) vertices in-adjacent to any of the first vertices (i) occupy the next places, (iii) vertices 
in-adjacent to the vertices on second places (ii) are next, and so on; the last vertices in the sequence have no 
outoing lines. TopologicalSort(Dc) returns 6>c, which is a topological sort of the vertices in V(Dc)- As 
the elements in Sc are the vertices of Dc, the procedure ExpandSCC is called on Sc in order to obtain a 
topological sort of the strongly connected components of D c [u]. ExpandSCC will first set S to equate Sc, 
then replace each element w; of S with the result of stands For(wi). Each element w, will thereby be replaced 
with the strongly connected component Cj, which standsFor relates to c,. As soon as we have a topological 
sort S of the strongly connected components of D[v], the traversal of the strongly connected compontents 
can be performed and c-labels computed on the vertices therein. 
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Algorithm 3 Evaluate a Discussion 
Require: A discussion D[v]; 

Ensure: If there are stable c-labels for all vertices in D[v], then a function A : V(D[v}) — > {A, AD, R}, 
which returns the stable c-labcl for each vertex in D[v]; if there are no stable labels, then an error; 

l: procedure EvaluateDiscussion(D[u], P t ) 
Initialize: 

2: Empty D c [vl C, D c , S c , and S 

Build the transitive closure of the transitive preference rules applied in D[v]: 
3: D c [v] <— BuildTransitiveClosure(£>[i;], P t ) 

Find all strongly connected compontents of D c [v] and obtain their topological sort: 
4: C <— Enumerates CC(D c [v]) > C is the set of all strongly connected components of -D c [i;]. 

5: D c <- ContractSSC(D c H,C) 

6: S C <— TOPOLOGICAlSORT(L> c ) 

7: S <— ExpandSCC(5c) > An element of iS is a strongly connected component from C. 

Label all strongly connected components from the first to the last in their topological sort: 
8: A <- LabelSCC(L» c H, S) 
9: end procedure 

Obtain a directed acyclic graph Dc by contracting the strongly connected components in D c [v]: 
10: procedure ContractSCC(D c [?;], C) 

li: V(Dc) <— {w\, u>2, ■ ■ ■ , W\c\} > wi, ... ,w\c\ are vertices of Dc- 

12: for each c, G C do > Cj is a strongly connected component of D c [u]. 

13: standsFor(wi) Ci 

14: end for 

15: for each Wi G V(Dc) do 

16: for each Wj G V(Dc) s.t. Wi ^ uij do 

17: for each v G V (standsFor(wi)) do 

18: if 3i/w G L(L> c [v]) s.t. v' G V \standsFor(wj)) then 

19: Add the line from Wj to to L{Dc) 

20: end if 

21: end for 

22: end for 

23: end for 

24: end procedure 

Obtain a topological sort S of the strongly connected components of D c [v]: 
25: procedure ExpandSCC(Sc) 

26: S <- S C 

27: for each Wi in S do 

28: Replace with the result of standsFor(wi) 

29: end for 

30: end procedure 
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Algorithm 4 Label Strongly Connected Components 

Require: D c [v] and S, a topological sort of the strongly connected components of D c [i>]; 
Ensure: If there are stable c-labcls for all vertices in D[v], then a function A : V(D[v}) — > {A, AD, R}, 
which returns the stable c-labcl for each vertex in D[v]; if there arc no stable labels, then an error; 

l: procedure LabelSCC(-D c [v], S) 
Initialization: 



2: Add an empty c-sequence and an empty t-set on each vertex in l/(_D c [t>]) 

3: Let i in a be the position of the strongly connected component c in S, i.e., i = position{c, S) 

4: i <— 1 

Label each strongly connected component of D c [v] : 

5: while i < length(S) do 
6: if \V(ci)\ = 1 then 

7: if £ L(D c [v}) s.t. v' £ V{c t ), v" £ Uj=! v ( c j) then 

8: Append the c-sequence of the only vertex v' £ V(cj) with the label A 

9: else 

10: ComputeLabel(V 6 V(Cj), -D c [t;]) 

11: end if 

12: else 

13: Let v' be the newest vertex in V(c,-) 

14: LABELCOMPLEXSCC(c;, v') 

15: end if 

16: i <— « + 1 

17: end while 

Define the function A : V{D[v]) — > {A, AD, R} 

18: for each vertex v' £ V(D c [v]) do 
19: A(v') <~ (the last c-label in the c-sequence of v) 

20: end for 

21: Stop and return message: Stable labels found. 
22: end procedure 



To label the vertices in the strongly connected components of D c [u], Algorithm [3] calls the procedure 
LabelSCC on D c [v] and a topological sort S of the strongly connected components of D c [u]. Detail of the 
LabelSCC is given in Algorithm 01 

LabelSCC (D c [f], S) initializes by adding an empty t-set and an empty c-sequence to each vertex of 
VD C [«]. As discussed earlier in relation to the procedure ComputeLabel in Algorithm [2l the t-sets and 
c-sequences arc needed to compute c-labels at each traversal of a vertex. We then introduce the function 
position, which returns the positive integer denoting the position of a strongly connected component c in 
the topological sort S of the strongly connected components, i in Cj abbreviates positioners). Initialization 
ends by setting i = 1, so that the while loop moves from the first c in <S. At each iteration, the while loop 
considers the strongly connected component c at the ith position in <S, i.e., q. The while loop stops after it 
has processed the last element in the sequence S. length(S) is the number of elements in S. For a given Cj, 
the outer if block in the while loop checks if the Ci has one or more vertices: 

• If Ci has a single vertex, i.e., |V(cj)| = 1, then we must determine whether that vertex has incoming 
lines in Z? c [v]: 

— If the only vertex in a has no incoming lines, there are no vertices in -D c [u], which are relevant to 
its acceptability (cf., Definition 15.11 and Proposition and that vertex can be given the c-label 
A; 

— If the only vertex in a has incoming lines, then there are vertices that are relevant to its accept- 
ability. We therefore call the procedure ComputeLabel on that vertex and the graph D c [w]; 
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Figure 6: Figure |6(a)| show s a strongly connected component, say ci from the transitive closure D c [v] of some 
discussion D[v]. Figure |6(b) shows the stable c-labels obtained by calling LabelComplexSCC(ci, Ci). Figure 6(b) 
shows the stable c-labels obtained by calling LabelComplexSCC(ci, i2). We assume for simplicity that no vertex 
in ci has an incoming line in D c [v] that is not in ci. Observe from Figures [6(b) | and |6(c)| that the strongly connected 
component ci has no unique stable labels. Figure |6(d)| shows the unique stable labels on the strongly connected 
component from Figure 5(b) 



If Ci has more than one vertex, then each vertex in Ci is on at least one cycle. To label the vertices 
on cycles, one of the vertices must be chosen as a starting vertex. The problem with this choice is 
that an absolute criterion for choosing a starting vertex is abesent. To sec why, consider the strongly 



connected component in Figure 6(a) We observe that calling LabelComplexSCC on two different 
vertices gives different stable labels. This same problem arises when LabelComplexSCC is called on 
the largest strongly connected component in Figure O once on the vertex Pi, and in another call on Ci. 
In other words, we can obtain stable labels, but there are patterns of strongly connected components, 
in which the choice of the starting vertex for the labeling procedure influences the stable labels that are 
obtained. Not all complex (i.e., |V(c)| > 1) strongly connected components suffer from this problem: 
an example is the strongly connected component shown in Figure 5(b) If we assume that none of its 



vertices has incoming lines other than those shown in Figure 5(b) then unique stable labels exist for 
all of its vertices: whatever the chosen starting vertex for the labeling procedure, the stable labels will 
always be identical for each of its vertices. We discuss the uniqueness of stable c-labels in detail below. 

If no errors are reported, the while loop will terminate after all strongly connected components in S have 
been traversed, and all vertices therein assigned stable c-labcls. We then proceed to define the A function 
via the last for each loop. Each vertex v 1 <E D c [v] is considered, and A(u') is given the last c-label of the 
c-sequence of v'. 

We have noted above that stable labels may not be unique. We now consider this problem in more detail. 

Definition 5.30. Unique Stable C-Label. Let c be a strongly connected component of the transitive 
closure of a discussion, and such that \V(c)\ > 1. A stable c-label on a vertex v £ V(c) is unique if and 
only if LabelComplexSCC always assigns the same stable c-label on v, regardless on which vertex in c it 
is called. 

Suppose that there are in fact stable c-labels in a given strongly connected component c and that there are 
no lines in c that violate the line meaning (cf., i )4.2[) . so that LabelComplexSCC will not return an error. 
We then see four strategies to attack the question of whether the returned stable c-labels of the vertices in c 
are unique: 

1. Acyclical discussion. If there are no cycles in the transitive closure D c [v] of a discussion D[v], the 
problem of uniqueness of stable c-labels disappears. The absence of cycles in D c [v] makes each vertex 
of D c [v] a strongly connected component, so that the if condition in Line 6 of LabelSCC will verify 
for each vertex in D c [v] and LabelComplexSCC will not be called at all. There are two principal 
shortcomings of imposing acyclical discussions. Part of the expressive power would be eliminated, as 
various intuitively valid structures, such as the one in our earlier example (cf., fc|4.1[) . cannot be captured. 



24 



The other difficulty is that constraints must be placed on the process of building a discussion, if cycles 
are to be avoided at discussion-time. 



2. Brute force uniqueness check. The brute force uniqueness check would amount to call, for a given c, 
LabelComplexSCC on each of the vertices in c. In case the stable labels are not unique, the part of 
the discussion that the given strongly connected component captures should be revisited; after changes 
are made, EvaluateDiscussion would be run again. The proof of Proposition l5.29| points out that the 
running time of LabelComplexSCC on a strongly connected component c is 0((\V(c)\ + \L(c)\)(C(c) + 
l) + C(c)\V{c)\), where C(c) is the number of simple cycles in c. The part 0{{\V(c)\ + \L(c)\){C(c) + l)) 
is due to the computation of the number of simple cycles in c, so that it need be executed only once in 
the brute force uniqueness check. It is then apparent that the brute force uniqueness check will increase 
the complexity from 0((\V{c)\ + \L(c)\)(C(c) + 1) + C(c)\V{c)\) to 0((\V(c)\ + \L(c)\){C(c) + 1) + 
C(c)(\V(c)\) 2 ). The principal disadvantage in the brute force approach is the increase in complexity. 

3. Uniqueness check by random sample. Instead of running LabelComplexSCC on each vertex in Ci and 
comparing results, a random sample of the vertices could be chosen, and LabelComplexSCC would 
be called on each of the vertices in the sample. If LabelComplexSCC returns the same c-labels in each 
call on a vertex from the sample, the probability of these labels being the unique ones can be computed. 
Instead then of being certain that the c-labels are unique (as in the brute force approach), the computed 
probability would give a level of confidence in the c-labels being unique. If X is the sample of vertices, 
and S C V(c), then the complexity of this approach is 0((\V(c)\ + \L(c)\)(C(c) + 1) + C(c)\X\\V(c)\). 

4. Choose the first vertex via a heuristic. The idea here is to offer a heuristic for choosing the starting 
vertex in c, on which to call LabelComplexSCC. One possible heuristic comes from the saying "The 
one who has the last word laughs best." In other words, the starting vertex for labeling could be the 



last vertex among those in a given strongly connected component. In Figure 6(a) if Cx(ii, 12) was the 



last vertex added among the four vertices in that figure, then LabelComplexSCC(ci, Ci) is called 



and the resulting c-labels are given in Figure 6(a) This heuristic is meaningful in the example used 



throughout the paper (cf., ^4. 1|) : Pi and C2 were added last to the part of the graph, which encompasses 
the largest strongly connected component of D[i(g4 : )}. Calling LabelComplexSCC on either Pi or 
C2 gives the same stable labels. If LabelComplexSCC is called on a vertex older than Pi or C2, 
different c-labels will be obtained. We adopt this heuristic at present and include in the evaluation 
algorithm. As Dung [5] observes, the saying "he who has the last word laughs best" illustrates a 
very simple principle, on which people seem to often base the exchange of arguments. Given that 
LabelComplexSCC is called only once in this strategy, LabelComplexSCC will have the running 
time in 0((\V(c)\ + \L(c)\)(C(c) + 1) + C{c)\V{c)\). 

Observe that the first strategy is the simplest, while the second is the most complex. The third strategy 
is between the fourht and the second in terms of complexity. We use the heuristic given above in order to 
choose the newest vertex in the strongly connected component. This is reflected in Line 13 of LabelSCC, in 
Algorithm 31 where the newest vertex is chosen among the vertices of a given strongly connected component, 
and is input to LabelComplexSCC. It is clear that other relevant heuristics may be found, but we leave 
such discussions for future work. 

LabelComplexSCC is defined in Algorithm^] LabelSCC calls LabelComplexSCC on each strongly 
connected component c having more than one vertex. In addition to c, LabelComplexSCC is supplied 
with the vertex of c, say v, from which to traverse c. We gave earlier (cf., tj5.2.ip an informal outline of how 
c is traversed from v in order to compute the c-labels on vertices in c. We now discuss LabelComplexSCC 
in more detail via an example. 

The initialization of LabelComplexSCC starts by counting the simple cycles in c, which is stored in 
C(c). The queue Q is emptied, and the starting vertex v is added to Q. Q will carry the vertices that the 
outer for each loop in the while loop will traverse. All vertices are assumed acceptable at the outset, so 
that the c-label A is added to the c-sequence of the each vertex in c. The c-label A is taken as the initial 
hypothetical label because it is the weakest of the three labels (cf., Definition 15 . 25|) . Two counters p and q 
are initialized. The starting vertex v is called First. To see how LabelComplexSCC traverses c, observe 
first that the number of cycles C(c) gives the upper bound on the number of simple paths from any vertex 
to any other vertex in c. Assume then that we have a C(c) number of walkers for the given c. Recall from a 
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Algorithm 5 Label a Complex Strongly Connected Component 

Require: A strongly connected component c of the transitive closure D c [vi], s.t., |V(c)| > 1, and a vertex 
v e V(c); 

Ensure: If there are stable c-labels for all vertices in c, then at least two c-labels in the c-sequence of each 
vertex in V( 1 /[z;]); an error otherwise; 

l: procedure LabelComplexSCC(c, v) 
Initialization: 



2: C(c) <— CountSimpleCycles(c) > C(c) is the number of simple cycles in c. 

3: Empty Q 

4: Add v to Q 

5: Add the c-label A to the c-sequence of each vertex in c 

6: Call First the vertex v in Q 

7: q <- 

8: p <— 1 > p counts the number of c-labels in the c-scqucncc of First. 

Traversal: 

9: while Q is not empty do 
10: for each vertex v in Q do 

11: Delete v from the queue Q 

12: for each u' E V(c) s.t. 3w' G L(c) do 

13: if the result of ComputeLabel(w', D c [vi\) is not an error then 

14: if v' 7^ firsf then 

15: Append the c-sequence of v' with the result of ComputeLabel(w', D c [vi\) 

16: else 

17: if q < C(c) then 

18: + 1 

19: else if q = C(c) then 

20: Empty Q 

21: Append the c-sequence of u' with the result of ComputeLabel(u', D c [vi\) 

22: q <— 

23: p <— p + 1 

24: end if 

25: end if 

26: Add w' to Q 

27: if the last two labels in the c-sequence of First are identical then 

28: Empty Q and return message: Stable labels found. 

29: For each vertex in V(c), keep only the last label in its c-sequence, delete others. 

30: else if p = 4 then 

31: Empty Q and return error: c has unstable labels. 

32: end if 

33: else 

34: Empty Q and return error: Disallowed graph structure encountered. 

35: end if 

36: end for 

37: end for 

38: end while 

39: end procedure 
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discussion above (cf., ij5.2.1[) that tach walker obeys the following rules: (i) it takes equal time to traverse a 
vertex; (ii) it can only go forward (i.e., over lines that start in a vertex); and (hi) no two walkers will start 
from First and return to First along the exact same path. 

Consider now again the strongly connected component c in Figure 5(b) having four simple cycles, i.e., 
C(c) = 4. We shall assume for simplicity the following: (i) c is a strongly connected component in the 
transitive closure D c \vj\, of some given discussion D[vi\; and (ii) none of the vertices in c has an incoming 
line in -D c [t>i] that is not in c. Let C2 be the newest vertex in c, and is therefore called First and added to the 
queue Q. With C2 in Q, LabelComplexSCC enters the while loop. The outer for each loop will delete 
First from Q, while the inner for each loop will consider each line that starts in C2. We put all four walkers 
on C2 and move them along the line C2i2 to ±2- Since ±2 ^ C2, the if condition in Line 14, in the inner for 
each loop verifies and ComputeLabel(:l2, -D c [i>i]) is called. The c-sequence of ±2 thus becomes (A, R) and 
±2 is added to Q and the walkers arc at ±2- The while loop then processes ±2- the walkers move along the 
line i2Pi,i to P11, and the c-sequence of P1.1 becomes (A, R) and Q contains only P11. Because there are 
three lines starting in P1.1 and none of the vertices on which these lines end is First, the inner for each loop 
will be adding three vertices to Q. 

We consequently send the walkers along three different lines that start in Pi,i: walker A will move to ii, 
B to i4, and the other two, C and D to ±3. It is important to observe here that the walker A will reach the 
vertex First in the least number of steps, while one of the walkers C or D will reach First in the most steps. 
Suppose that D is the last to arrive to First. We can now explain the role of the counter q. When A arrives 
to First, it will apply the ComputeLabel procedure, which will return a c-label based on the last c-label 
in the c-sequence of ii, which in turn was computed from the last c-label in the c-sequences of vertices 
Pi : 2 and Pi ; 3. At the time when A computes the label on C2, the walker C will be computing the label on 
Pi 2- Moreover, it is only after A has appended the c-sequence of C2 that D will be computing the label 
on Pi t 3. If D adds a label to Pi. 3 that is different from the label that A had on P13, D will may end up 
computing a different label on C2 from the label that A computed. The point is that it is not appropriate to 
let A append the c-sequcncc of First before the last walker returns to First, because the labels computed by 
the walkers before D do not account for all of the information in c. It is only after the last walker arrives to 
First that we know that all vertices of c were traversed. The else block in Lines 16-25 in Algorithm [5] verifies 
when a walker arrives at First, and it is only when the last walker has arrived that the c-sequence of First is 
appended with a label. Observe thus that q counts the number of walkers arriving at First, while p counts 
the number of c-labels in the c-sequence of First. Figure [7] shows the result of applying LabelComplexSCC 
to c in Figure |5(b)| 

It is on the basis of patterns of c-labels in the c-sequence of First that LabelComplexSCC detects the 
presence or absence of stable c-labels in a complex strongly connected component. When no stable c-labels 
can be found, no pair of same c-labels will be identified in the four first c-labels of the c-sequence of First. 
Otherwise, stable labels are present and the algorithm will return a stable label for each vertex. The proof 
of Proposition 15 . 291 discusses in detail the case of unstable labels. Figure 8(a) gives an example of a complex 
smallest justification that has no stable c-labels, while Figure 8(b) illustrates a partial result of the application 



of LabelComplexSCC to the strongly connected component in Figure 8(a) 



6 Acceptability Condition Revisited 

We wrote in Equation [2] above (cf., g3j) that AC(I D ,T(I D ), O d ) holds if and only if Vp G In{I D ) U In{0 D ) U 
In{T{I D )), AC{p). After we have introduced the EvaluateDiscussion procedure (cf., ij5.2.2l and Algorithm 
[3]), we can provide the revision of the preliminary definition of the acceptability condition (cf., Definition 
I3TD . 

Definition 6.1. AC (revised) . The application of the RE method T to the input Id to produce the output 
Od is acceptable, denoted AC(Id,T(Id),Od) if and only if: 

Vp E In(I D ) U In(0 D ) U In(T(I D )), AC(p) (79) 

where: 

AC(p)iffA(\ v (p))e{A,AD} (80) 
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Figure 7: Traversal of complex strongly connected component in Figure 5(b) by the procedure LabelComplexSCC 
in Algorithm [S] The graph in Figure 5(b) has four simple cycles (i.e., C(c) = 4). The content of the queue Q is given 



on the right hand side of the figure above. Stable c-labels are found in this example. The stable label for any given 
vertex is the last label in the sequence of labels for that vertex. 



Remark 6.2. The definition above simply indicates that the stable c-label on the vertex Xy{p) that represents 
the proposition p, should either be A or AD. A(Ay(p)) returns that stable c-label, if it exists. Recall 
from Algorithm Q] that the function A is defined by calling EvaluateDiscussion on a discussion. We will 
therefore need to apply EvaluateDiscussion on all discussions that together have vertices representing 
all propositions in In(Ir)) U Itl{Od) U 7n(T(7jj)). The relationship between subdiscussions and discussions, 
highligthed in Proposition 15. 171 means that we will not necessarily need to apply EvaluateDiscussion to 
the discussion of each vertex representing a proposition in Iti(Id) Uin(Orj) U/n(T(/rj)), as some vertices may 
be within discussions of other vertices. 



7 Notes on Implementation 

The implementation of ACE graphs and of the associated retrieval and evaluation algorithms is not available 
at the time of writing. The implementation in progress is based on the adaptation of standard open source 
internet forum software. This choice is based on two observations: (i) internet forums are popular means for 
discussion, and are a well known kind of software, having evolved from bulletin board systems of the early 
1970s; and (ii) a discussion in ACE amounts to a forum discussion performed according to a set of simple 
rules. By default, a discussion in an internet forum contains a collection of untyped posts. Any post may be 
a response to the original post (i.e., the root post), or a response to a later post. A forum discussion thus 
typically resembles an unlabeled tree, where each post is a vertex. To obtain an ACE discussion instead of a 
standard forum discussion, the following rules must be followed by the participants: 

1. Any post is either an information, inference, conflict, or preference post. 

2. Any post that is not the first post in a discussion, must be related to another post according to the 
meaning of the To relationship. 

Compared to a classical forum, an ACE forum is thus one where a user chooses the label for a new post, 
and relates that post to others. The first rule above ensures that we have the label for any post, while the 
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Figure 8: Figure [8(b) | shows part of the traversal of the complex smallest justification in Figure [8(a)] by the procedure 
LabelComplexSCC in Algorithm [5] Only part of the traversal is shown as the rest of it can be straightforwardly 
reconstructed by the reader. The graph in Figure 8(a) has two simple cycles (i.e., C(c) = 2). The content of the 
queue Q is given on the right hand side in Figure |8(b)[ The strongly connected component c in Figure |8(a)| has no 
stable labels. 
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second rule guarantees that no post is disconnected from the others. A discussion in an ACE forum can thus be 
interpreted as an ACE graph (or ACE discussion) , on which we can perform retrieval and evaluation operations 
via the algorithms discussed earlier. The evaluation algorithm provides to participants the indication on the 
acceptability of each post, so that they can, in case of rejection, intervene and respond in defense of their 
claims. 

8 Discussion and Related Work 

This work is the continuation of our efforts to advance the analysis of decision making in requirements 
engineering. At the 2006 edition of this conference, we discussed the problem of the acceptability of goal 
models [TT] via their justification. We argued at the time that modeling choices - e.g., the inclusion or 
exclusion of some information about the system-to-be and its environment - should be justified for a goal 
model to be acceptable. A manual procedure for justifying and evaluating justifications was offered. The 
concept and procedure borrowed from the contributions on the analysis of arguments in artificial intelligence. 
A justification amounted to a tree, where any vertex can either support or attack other vertices. That 
work was subsequently extended [12j to analyze the clarity of information offered when justifying modeling 
choices; these manual techniques can identify the use of unclear information, by detecting, e.g., ambiguity 
and vagueness. This work was subsequently applied to the analysis of the acceptability of changes in Unified 
Modeling Language models [ID] . The present work advances our prior results in several respects: (1) ACE 
allows participants to express preferences over information, and applications of inferences, conflicts, and 
other preferences in ACE graphs. Our prior analysis of acceptability via justification could not account for 
preferences, the set of inferences and conflict rules was closed (i.e., two inference rules were available and one 
conflict rule), and no forms of meta-reasoning could be captured (one could not express that the application 
of an inference rule is in conflict with the application of another inference rule, that a conflict may be in 
conflict with the application of an inference rule, and so on). (2) ACE offers algorithms for the retrieval of 
information relevant for the evaluation of acceptability; no such features were available for our justification 
graphs. (3) The evaluation of acceptability in ACE is automated via the evaluation algorithm outlined above; 
acceptability was evaluated manually in justification graphs. In conclusion, ACE is (i) more expressive (due 
to the presence of preferences and the support for forms of meta-reasoning), (ii) more "practical" (due to 
the presence of retrieval and evaluation algorithms), and (iii) more general (as argued throughout the paper) 
than the goal-oriented approaches, which we suggested previously. 

The language in ACE, and more precisely, the choice of the four labels - information, inference, conflict, 
and preference - was influenced by the initiative towards a core ontology for argumentation in artificial 
intelligence, within the Argument Interchange Format (aif) [3]. AIF has recently been suggested to facilitate 
the representation and exchange of data between various tools and agent-based applications that rely on 
arguments. The basis for AIF is the AIF Argument Network, which is "the core ontology for argument entities 
and relations between argument entities" [3|. The notion of argument is a construct in aif, defined as a 
particular subgraph in an argument network. It is by placing restrictions on, or by specializing the concepts 
in the argument network that classical argumentation frameworks can be obtained. ACE thereby reuses the 
core ontology of AIF for the labels in ACE graphs. To the best of our knowledge, no framework based on 
AIF and comparable to ACE in terms of the language and the retrieval and evaluation algorithms has been 
suggested. 

Validation is an old problem in RE, and has been raised in particular in relation to the very early require- 
ments elicited from the parties involved in re. Leite and Freeman argued in an important paper |14j that 
requirements should be elicited from different viewpoints, and "that examination of the differences resulting 
from them can be used as a way of assisting in the early validation of requirements" . They suggested a 
language for capturing viewpoints, and heuristics for a syntacticly oriented analysis of views to the aim of re- 
solving their inconsistencies. This approach provides inputs to the negotiation required to reconcile different 
opinions. An attractive characteristic of their proposal is that it is a means of validation applicable very early 
in the elicitation of requirements. We are very close to their work in this motivation, although our proposal 
differs in several important respects. ACE has a considerably simpler language than their framework. Since 
automated reasoning about acceptability happens in a propositional framework in ACE, we can accommodate 
various forms of RE artifacts. As we treat propositions as atoms, Leite and Freeman's approach can go 
into more detail, and study the structure of the propositional content. While they can point precisely the 
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disrepancies between views, we can help by evaluating the outcomes of a discussion of these discrepancies. 
Nothing similar to the automated evaluation of acceptability is present in the viewpoint resolution method. 
Discussions are not studied in detail. ACE is complementary in this respect, as it can be used to record and 
evaluate discussions of views and their inconsistencies. Gervasi and Nuseibeh [7] check predefined properties 
on models generated from parsed text to identify nontrivial inconsistencies. While AC (Id, T(Ijj), Od) indi- 
cates agreement about these artifacts, it certainly does not entail the internal consistency of the Id, T(I d ), 
and Od', inconsistency can be present even if agreement is present: inconsistency in that case remains un- 
detected, making ACE complementary to any approach tailored to detect nontrivial internal inconsistencies. 
Validation of late requirements is well illustrated in a recent paper from Uchitel et al. [21] . They establish the 
relation between scenarios and goals via "fluents that describe how the events of the operational descriptio 
change the state of the basic propositions from which goals are expressed." Graphical animations can be 
synthesized from scenarios and goal model checking over scenarios is enabled to guide animations through 
goal violation traces. Animations are subsequently presented to the relevant parties for discussion: 

"The users were given a view to interact with and asked to perform certain tasks. This initiated discussion 
as to how well the system supported their achieving their goals, and what might be changed in order 
to make it more effective. Suggestions about variations in the order in which activities were performed 
could be incorporated into the model with a few minutes work." 

ACE can complement such an approach, especially when user-centered sessions involve the asynchronous 
participation of geographically distributed users, so that discussion via forum-like tools becomes relevant. 
Boehm's Win Win groupware supports negotiation of requirements via the general WinWin approach. It 
is usually defined as [1] "a set of principles, practices, and tools, which enable a set of interdependent 
stakeholders to work out a mutually satisfactory (winwin) set of shared commitments." WinWin differs from 
ACE in that it focuses on the negotiation context, which differs from discussions on which ACE focuses. ACE 
is not tailored to negotiation. 

Absence of validity can reflect errors in the rationale of the decisions taken when a method is applied. 
The primary aim of design rationale (dr) research is to capture the why behind decisions in a design activity. 
The classical IBIS method [4] starts with a participant who posts the root issue of an ibis tree. Others 
then post positions (i.e., ways of resolving issues) and arguments (to support or object to positions). Issues, 
positions, and arguments are related via some of the allowed relationships: generalize, specialize, object, 
support, replace, question. The process stops when consensus has been reached regarding the resolution of 
issues. Subsequent dr methods, as reviewed by Louridas and Loucopoulos |15j . share many characteristics 
with ibis. The principal novelty of ACE with regards to these other DR methods lies in the way it answers 
the relationship expressivity question: What are the relationships between concepts in the DR method, and 
how are they defined? At stake in this question is how to build a dr approach in the face of the multitude of 
potentially relevant relationships; Louridas and Loucopoulos highlight this problem in the following passage: 

"A fixed set of links [i.e., relationships] limits both the expressive and the functional capabilities of the 
[design rationale] model. Regarding the expressive weaknesses of any such attempt, the sheer number 
of the proposed relationships in the various [design rationale] approaches and the differences in their 
semantics from approach to approach indicate that it is difficult to arrive at a widely accepted set of 
predefined links. Each approach commits to a certain set, but there is no reason to believe that one of 
these sets is innately better than the others." ([15]: p. 222-223) 

This leads Louridas and Loucopoulos to leave out the definitions of the relationships in their Reasoning 
Loop Model, which is their synthetic proposal for reflective design. In doing so, they adopt the so-called 
free-link approach to the construction of a dr methods. This differs from the classical fixed-link approach, 
where a closed set of relationships is defined, and their meaning set once and for all. The benefit of free- 
links approach is that it leaves considerable freedom in use; its main downside is that it is hard to define, 
even manual, techniques for the analysis of its graphs. The fixed-link approach allows for the definition 
of analysis techniques, although the tendency to use many relationships renders the definition of alorithms 
for the analysis of graphs difficult. ACE adopts a third option, which has not been explored elsewhere 
to the best of our knowledge. ACE has a single relationship, the meaning of which are derived from the 
labels of vertices that it connects. An inference, conflict, and preference label does not designate a specific 
inference rule, conflict rule, or preference rule: one inference vertex may capture the application of modus 
ponens, another the application of defesible inference; one preference vertex may capture the application of a 



31 



transitive preference order, while another may capture the application of an intransitive preference. Finally, 
and very importantly, ACE allows one to accept or reject the application of an inference, conflict, and/or 
preference rule, which is clearly impossible in the fixed-links approach to the construction of dr methods. If 
links are fixed, no meta-reasoning on them is allowed by the DR method itself. Making the links free is no 
better solution: what are then the criteria to accept or reject an arbitrary link? ACE is interesting because it 
leaves the freedom in the actual choice of an inference, conflict, or preference, while at the same time fixing 
how an inference, conflict, or preference relates, in terms of acceptability, to another information, inference, 
conflict, or preference vertex. E.g., ii — ► I — ► ±2 tells us in terms of acceptability that ii does not make 
i 2 unacceptable, but is evidence to the acceptability of ±2, and this regardless of the actual inference applied 
to conclude ±2 from ii. By writing ii — > I — > ±2, we may be abbreviating the expression "ij supports I2", 
where "supports" has the same meaning as in ibis. I in ij — ► I — ► ±2 is thus locally defined (as opposed 
to fixed- lines approach), but we still have precise criteria for accepting or rejecting any local reading of I in 
ii — > I — > i 2 (as opposed to the absence of these criteria in the free-links approach): we will reject it if the 
evaluation algorithm labels it R. Overall, ACE shows a noveal way to balance the tradeoff between freedom 
in use and the automated analysis of graphs, without falling into extremes of the usual fixed-links, or the 
recent free-links approach to the construction of dr methods. 



9 Conclusions and Future Work 

Perfectly valid RE artifacts capture exactly what the stakeholders really need. We distinguished this absolute 
validity from relative validity. The latter asks if the stakeholders agree on the content of an re artifact, 
being thereby relative to the stakeholders. Checking relative validity inevitably leads to a discussion between 
the stakeholders and the requirements engineer. This paper offered the acceptability condition on an artifact 
as a proxy for relative validity, and the ACE framework for the evaluation of the acceptability condition via 
the analysis of discussions. If the acceptability condition holds, then this signals that the relative validity 
verifies for the given artifact and for the participants in a given discussion. The ACE framework incorporates a 
simple, but expressive language for the representation of the pieces of information exchanged in a discussion, 
and the inference, conflict, and preference relationships between these pieces of information. Discussions are 
represented via directed labeled graphs. We suggested an algorithm to retrieve subgraphs in order to inform 
the discussions between the participants. ACE incorporates another algorithm to evaluate the acceptability 
condition in these graphs. Data from actual use will expectedly open many questions regarding usability and 
relevance in practice. 



32 



A Proofs 



A.l Proof of Proposition 

Proof. We prove Proposition 15 . 91 by induction on the length of a path P in an ACE graph G. Suppose that 
v G V(G) and there are various paths in G that end in v. 

Take a path P = v" — ► v' — > v. Consider all possible combinations of labels on v' and v. Of all possible 
combinations, twenty four are allowed by the meaning of the To link in an ACE graph. All twenty four are 
listed in Table [T] We discuss in turn the first three cases, then skip the others as they become obvious after 
the first three: 

1. P = v" — > i e ) — ► ie^ Table [T] indicates that the inference rule application I s (v" , i e ) concludes 
i e . If the inference rule application is not acceptable, then its conclusion is not acceptable, so that 
I s {y",± e ) is relevant to the acceptability of i e . v" is the premise to the inference rule application 
I s (V',i e ): if v" is not acceptable, then the inference rule application will not be acceptable, so that 
v" is AC-relevant to the inference rule application, and thereby to the conclusion of the inference rule 
application. Both v" and I s (v", i e ) are therefore relevant to the acceptability of i e . 

2. P = v" — > C s (v",i e ) — > i e : The conflict rule application C s (v",i e ) makes v" attack i e . If the 
conflict rule application is not accepted, then i e will be accetable (at least as far as the current path is 
concerned). If instead the conflict rule application is accepted, but the dominant vertex v" is not, then 
i e still is accepted. It follows that both v' and C s (v", i e ) are relevant to the acceptablity of i e . 

3. P = v" — > P s (w", i e ) — > ie'- The preference rule application P s (u", i e ) makes i e strictly less preferred 
than v", that is, i e is dominated by v" . If the preference rule application is not accepted, then i e will 
not be dominated. If instead the conflict rule application is accepted, but the dominant vertex v" is 
not, then i e still is accepted and not dominated. Both v' and P s (i>", i e ) are clearly relevant to the 
acceptablity of i e . 

4. By applying the same reasoning as above for the remaining twenty one cases, observe that both v" and 
v' are relevant to the acceptability of v, and this regardless of the labels on all three vertices (and as 
long as the meaning of the To link are not violated). 

From there on, we extend the path with an additional vertex v'", so that P' = v'" — > v" — >v' — > v. If 
we consider separately the subpath P x = v'" — > v" — ► v', and study all combinations of labels on v'", v" 
and v' that are in accordance with the meaning of the link To, we need to consider exactly the same cases 
as above for the initial path P = v" — > v' — ► v. For each case, the conclusion will be identical: v'" and v" 
are both relevant to the acceptability of v'. As v' is relevant to the acceptability of v, we conclude that v'" 
and v" are both relevant to the acceptability of v. It is trivial to see that whatever the number of vertices 
on a path between a vertex v x and the vertex v, v x is relevant to the acceptability of v. □ 

A. 2 Proof of Proposition [5.161 

Proof. We first prove that the algorithm (i) does not loop indefinetly. V(G) and L(G) are finite; the while 
loop explores only incoming lines to a given vertex, and never adds the same line or vertex twice to D[v]. It 
follows that the algorithm will never loop indefinetly. 

We prove by contradiction that the algorithm (ii) returns all direct and indirect vertices in favor of or 
against the starting vertex v. Suppose that there is a vertex v' that is cither in favor or against the starting 
vertex v, and that is not visited by the algorithm. The inner for each loop (Lines 7-15) moves from the 
starting vertex along its incoming lines to its nonvisited adjacent vertices, adds these to the queue Q, and 
removes the starting vertex. The while loop guarantees that any vertex added to Q is visited, along with 
its outgoing lines. The while loop thereby ensures that any vertex in G having a path to the starting vertex 
is visited. If v' was not visited by the algorithm, then v' is not on a path that ends in v. It is therefore a 
contradiction that v' is in favor or against v, but that it has not been found by the algorithm. 

Finally, we prove that the algorithm (Hi) has the running time in 0(\V(D[v])\ + \L(D[v])\). The if-then 
blocks in the inner for each loop (Lines 7-15) guarantee that no vertex or line in G will enter Q more than 
once, and that all lines and vertices visited for the first time will be added to D[v]. It follows that the worst 
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case arises when D[v] = G, so that the algorithm will traverse all lines and vertices of G, which gives the 
0{\V{G)\ + \L(G)\) as the upper bound on the time complexity, and 0(|F(D[v])| + |L(Z?[u])|) as the time 
complexity for the algorithm. □ 

A. 3 Proof of Proposition 15.271 

Proof. We first prove that Algorithm [2] (i) does not loop indefinetly. The for each loop considers only the 
vertices that are in-adjacent to u,;. The number of vertices in D[v] is finite, so that inDegree{vi 1 D[v\) is finite. 
The algorithm therefore always terminates. 

We now prove that Algorithm^ (ii) returns the overruling c-label among the c-labels propagated from all 
in-adjacent vertices to Vi in D[v\. The for each loop ensures that the t-sct of Vi receives a c-label from 
each vertex in D[v] that is in- adjacent to Uj, so that all c-labels propagated from these vertices are included 
in the t-sct. It is obvious that the last if block (cf., Lines 10-16) is simply a rewriting of the inference 
rules for multiple c-labels (cf., Definition 15. 25| . so that the appropriate overruling label is computed by the 
ComputeLabel procedure. 

We finally prove that Algorithm^ (Hi) has the running time in 0(inDegree(vi, D[v])). This is obvious, as 
the for each loop considers each vertex in D[v] that is in-adjacent to Uj. □ 

A. 4 Build the Transitive Closure of a Discussion 

Any discussion D[vi] can contain preference rule applications. All preference rule applications need not 
be the applications of the same preference rule. That is, different preference rules can be applied in a 
discussion. Some of these preference rules may be transitive, so that it becomes necessary to build the 
transitive closure -D c [w 2 ] of these transitive preference rules on D[vi\. This is accomplished via the pro- 
cedure BuildTransitiveClosure in Algorithm [6] The procedure takes a discussion D[vi] and a set 
P T . Each member of P T is a set of applications of one same transitive preference rule; e.g., P T = 
{{Pi,i,Pi,2i ■ ■ ■}, {P2,i; p 2,ij ■■■},■■ ■}, where {Pi,i,Pi,2, ■ • ■} is the set of applications of the preference rule 
Pi) {P2,i)P2,2) ■ ■ ■} is the set of applications of the preference rule P2, and so on. The potential presence of 
more than one transitive relation in a discussion and the representation of the application of the transitive 
relations via preference vertices (and not direct lines between vertices) makes it impossible to reuse as-is the 
standard algorithms for the computation of the transitive closure of a directed graph. 

BuildTransitiveClosure initialzes in two steps. The first step is to copy the vertices and lines of the 
D[vi] to the new graph D c [vi], so that all original vertices and lines are kept. The second step is the for each 
loop in Lines 3-13. The loop considers each set pj G P T of applications of the same transitive preference 
rule. An empty graph Zj is created for each pj . Recall that a preference rule application relates two sets 
of vertices, that is, any member of pj is of the form P(A, B), where A is the set of vertices of D[v], each of 
which is made strictly more preferred by the preference application P(A, B) than each of the vertices in the 
set B. I.e., any v £ A is strictly more preferred than any vertex v' £ B. The purpose of Zj is to carry only 
all vertices, on which any member of pj is applied. E.g., if P(A, B) £ pj, then Zj will contain all vertices in 
iUfl and all lines from v £ A to the vertex P(A,B), and all lines from the vertex P(A, B) to each vertex 
v' £ B. The iteration of the for each loop in Lines 5-12 on P(A, B) will first add to Zj (via the for each 
loop in Lines 6-8) the vertices of A and lines from each vertex in A to P(A, B). then add to Zj (via the for 
each loop in Lines 9-11) all vertices of B and lines from P(A, B) to each vertex in B. 

After the initialization step is performed, a set of graphs Zj is available. A graph Zj contains only all 
preference rule applications from pj and all vertices from D[v], to which these preference rule applications 
were applied. Observe that a Zj need not be a connected graph. Consider the graph below. 

(Ex.18) 

il — >■ Pi,l(ii, 12) — 3- 12 — >■ Ci(i2, — s- i3 — 3- Pi, 2(13, 14) — *- 14 

Suppose that the graph above is a fragment of a discussion, and Pi,i(ii,i2) and Pi j 2(i3, 14) are the only 
applications in that discussion of the same transitive preference rule Pi, then p\ = {Pi,i(ii, ±2), Pi, 2(12, 13)}- 
The initialization step will give Z\ for p\, whereby Z\ is shown below. 
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Algorithm 6 Build the Transitive Closure of a Discussion 

Require: A discussion D[vi] and a set P T . Each member pj of P T is the set of all applications of the same 

transitive preference rule; 
Ensure: The transitive closure D c [vi] of transitive preferences in P T 



1: procedure BUILDTRANSITIVECLOSURE(I?[w i ], P T ) 
Initialization: 

2: V{D c [ Vl ]) <- V{D[v,j\) and <- L{D[v z ]) 

3: for each set of transitive preference applications pj G P T do 

4: Create an empty graph 

5: for each w £ pj do 

6: for each v'v G L(.D [«,-]) and w is a preference on u' do 

7: Add «' to V(Zj-) and add j/u to L(Zj) 

8: end for 

9: for each vv' G L(£)[v,-]) and u is a preference on u' do 

10: Add v' to y(^) and add vv' to 

11: end for 

12: end for 

13: end for 

Identify and add new lines to D c [vi] 

14: for each Zj do 

15: for each connected subgraph Zjk of Zj do 

16: Create an empty queue Wj t k 

17: Create an empty queue Xj^ 

18: for each v G V(Zj i k) s.t. ^h/u £ L(Z^ k ) do 

19: Add u to Wj,jt 

20: end for 

21: if Wj,fc is empty then 

22: Choose a random vertex v in Z^fc s.t. 3vv' G L(Z^k) 

23: Add « to Wj^fc 

24: end if 

25: while Wj- fe is not empty do 

26: for each vertex v in do 

27: Delete v from W* k 

28: if u G j>j then 

29: Append v to Xj.k 

30: for each u' ^ t> in X^fc do 

31: if there is a path from v' to t> in Zj t k then 

32: for each v'" G V(Z,- ifc ) s.t. 3W' G L(Zj,fc) do 

33: if v'v'" i L{D c [v t ]) then 

34: Add v'v'" to 

35: end if 

36: end for 

37: end if 

38: end for 

39: end if 

40: for each v" G V(Zj.k) s.t. v" was never before in Wj.k and 3W G L{Zj^) do 

41: Add v" to Wj-,fc 

42: end for 

43: end for 

44: end while 

45: end for 

46: end for 

47: end procedure 
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(Ex.19) 



Pl,l(il,i 2 ) 



■ Pi, 2(13, 14) 



The graph Z\ above is not connected and has two connected subgraphs. The for each loop in Lines 14-46 in 
Algorithm [5] considers each Zj. For a given Zj, each of its connected subgraphs Zj t k is processed in turn. For 
a given Zj t k, two queues are created: Wj.k will carry vertices that have not been traversed and thereby need 
to be traversed, while Xj t k will contain preference rule appliactions from pj, which were already traversed. 
Lines 18-24 add vertices to Wj k'- if there are vertices in Zj^ that have no incoming lines, then these vertices 
are added to Wj if there are no such vertices, a random vertex with at least one outgoing line is added to 

At Line 25 in Algorithm [6l there is at least one vertex in Wj t k so that we can enter the while loop. Each 
vertex in Wj t k will first be removed from W^k in Line 27. The if block in Lines 28-39 will check if the vertex 
v is a preference rule application from pj. If so, v will be added to the queue Xj.k, which contains members 
of pj, which were already visited through the while loop. After v is added to Xj t k, we consider each of 
the preference rule applications v' already in Xj t k and determine if there is a path in Z^k from v' to v. If 
such a path exists, a line is added in Line 34 from v' to each of the vertices in Zj t k, to which v applies. For 
illustration, let the graph below be a Zj t k. 

(Ex.20) 

ii — >■ Pi,i(ii, ±2) — i 2 — >■ Pi, 2(12, {i3, 14}) — >■ 13 



If we run the while loop on the graph Zjk above, ii will be the first vertex added to Wj t k- Given that ii 
is not a preference rule application, the condition in Line 28 will not verify, so that the for each loop in 
Lines 40-42 will be executed, and result in adding Pii(ii,i2) to Wj t k- The while loop will then consider 
Pi i(ii, 12), and the condition in Line 28 will verify. Pi,i(ii, 12) will be added to Xj t k, which is empty. The 
for each loop in Lines 40-42 will then add ±2 to Wj.k- As for ii, no change will be made to Xj t k when 
the while loop runs on ±2- After ±2, the while loop will consider Pi 2(i2 ; {13, 14})- This preference rule 
application will be added to Xj.k, which already contains Pi,i(ii, i2)- As there is a path from Pi,i(ii, 12) 
to Pi l 2(i2 ) {^3) 14}); the condition in Line 31 will verify, and two lines will be added to D c [vi\: Pi i i(ii, i2)i3 
and Pi.i(ii, ±2)14, as shown in the graph below. 

(Ex.21) --^^^ 

ii — *- Pi,i(ii, 12) — ± 2 — s- Pi, 2(12, {13, 14}) — >- 13 



Proposition A.l. The procedure BuildTransitiveClosure applied to a discussion D[vi] and a set P T 
(whereby each member of P T is a set of applications of one same transitive preference rule) (i) does not loop 
indefinetly, (ii) returns the transitive closure D c [vi] of all transitive preference rule applications P T on D[vi], 
and (Hi) has the running time in 0(\V(D c [vi])\ + \L(D c [vi])\). 

Proof. We first prove that BuildTransitiveClosure (i) does not loop indefinetly. The for each loop in 
Lines 3-13 considers each pj £ P T . As the number of applications of transitive preference rules is below the 
number of vertices in D[vi], and D[vj] is finite, the first for each loop always terminates. The for each 
loop in Lines 14-46 considers each Zj, the number of which equals to \P T \, which is finite. The for each 
loop in Lines 18-20 always terminates, as |V(Zj.fc)| is finite. The for each loop in Lines 32-36 also always 
terminates because \V(Zj.k)\ is finite. Xj.k is also finite, so that the for each loop in Lines 30-38 always 
terminates. The for each loops in Lines 15-45 and 14-46 will always terminate only if the while loop always 
terminates. The latter stops when Wj.k empties. Wj.k will empty after all vertices in Zj.k were visited once. 
The procedure BuildTransitiveClosure therefore does not loops indefinetly. 
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We now prove that BuildTransitiveClosure (ii) returns the transitive closure D c \vi\ of all transitive 
preference rule applications P T on D\vi\. We prove this by contradiction. Remark first that all applications 
of transitive preference rules are input to the procedure via the set P T . Each member pj of that set is a set 
of vertices in -Dhvj], and each of these vertices is a different application of one same transitive preference rule. 
We therefore know from the outset the preference rules that are transitive and their applications in D[cj]. 
Suppose now that D c [vi] is returned by BuildTransitiveClosure(D[wj], P t ), and that it is missing a line 
Pi^u from a transitive preference rule application P1.1 to the vertex v, as shown in the graph below. We 
thus assume that the graph below is a subgraph of D c [vi], and that there are no lines in D c [vi] between the 
vertices shown below other than the lines shown below. 

(Ex.22) 

v " — *-Pi,i(v",t>') —*v' -^PiM v '< v )^ v 

There are three ways for the procedure to miss to add P^iv to D c [vi\: 

1. At initialization, the for each loop in Lines 3-13 does not add the line u'Pi 2 to the relevant Zj. This 
could only happen if that line was not in L(D[vi\), which contradicts the premise that the line is in 
fact in D\vi\. 

2. At initialization, the for each loop in Lines 3-13 places P^i in some Z a and Pi^ in some Z^, with 
Z a 7^ Zb. This is only possible if P1.1 and Pi^ were in two different members pj of P T . If that was the 
case, then P^i and Pi^ are applications of two different transitive preference rules, and the line P^if 
should not be in D c [vi] anyway. 

3. Let P^i and Pi 2 be in V(Zi t i). If there is no path in Z11 from to Pi^, then the while loop will 
not add the line Pi.iu to D c [vi\. That path is absent is Pij and Pi ; 2 are in two disconnected subgraphs 
of Zi t i, which is a contradiction, as Z\ \ is by definition a connected subgraph of Z\ (cf., Line 15). 
That path can also be absent if Z\_\ is a connected graph. This, however, is again a contradiction, as 
we assumed that a a path from P1.1 to Pi, 2 is present in D[vi\. 

We conclude that BuildTransitiveClosure returns the transitive closure -D c [i>i] of all transitive preference 
rule applications P T on D[vi\. 

We finally prove that BuildTransitiveClosure (Hi) has the running time in 0(V(D c [v}) + L(D c [v])). 
The upper bound on running time in the initialization step is 0(| ^(D^i]) + This is a pessimistic 

estimate, as it assumes that all vertices in D[vi] are linked to at least one application of a transitive preference 
rule. The pessimistic estimate for the main for each loop is 0(|F(D c [wi])| + |L(-D c [ui])|), because it will con- 
sider each Zj, and each Zj± only once, and the while loop will visit each vertex in Zj^ only once. We conclude 
that 0(\V(D c [v l })\ + \L(D c [vi})\) is the upper bound on the running time of BuildTransitiveClosure. □ 

A. 5 Proof of Proposition [5.291 

Proof. The proof of Proposition 15.291 is a combination of propositions on the following procedures called in 
Algorithm [3] 

• Proposition IA.1I on the BuildTransitiveClosure procedure, which is called on a given discussion 
D[v] and given a set of transitive preferences P T ; 

• Proposition IA. 21 on the Enumerates CC procedure, which is called on the transitive closure D c [v) of 
a discussion D[v]; 

• Proposition IA. 31 on the ContractSSC procedure, which is called on the set C of strongly connected 
components of -D c [i']; 

• Proposition IA.4I on the TopologicalSort procedure, which is called on the directed acyclic graph 
Dc, in which each vertex represents a strongly connected component from C; 
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• Proposition ! A. 5l on the ExpandSCC procedure, which is called on the topological sort Sc of the vertices 
in Dc', and 

• Proposition lA.6l on the LabelSCC procedure, which is called on D c [v] and the topological sort of the 
strongly connected components of -D c [i>]. 

We first prove that Agorithm [3] applied to a discusssion D[v] (i) does not loop indefinetly. Given 
that the procedures BuildTransitiveClosure, EnumerateSCC, ContractSCC, TopologicalSort, 
ExpandSCC, and LabelSCC all always terminate (cf., respectively, Propositions IA.1I [A.2i IA.3I IA.4i IA.51 
and lA.6[) when EvaluateDiscussion is called on a finite D[v] and a finite P T , EvaluateDiscussion always 
terminates if it is called on a finite D[v] and a finite P T . 

The proof that Agorithm [3] applied to a discusssion D[v] (ii) returns stable c-labels for all vertices in D[v] 
if they exist, an error otherwise follows trivially from Propositions IA.11 IA.21 IA.31 IA.4I IA.5[ and IA.6I 

Finally, we prove that Agorithm[3japplied to a discusssion D[v] has the running time in 0(C(D c [v])(\L(D c [v])\ + 
2\V(D c [v])\)), where C(D c [v]) is the number of simple cycles in D c [v]. This follows trivially from Proposi- 
tions lA ^ ll^ lAlIl |A^ lAl)l andKl as 0(C(D c [v])(\L(D c [v})\ + 2\V(D c [v})\)) is the worst of the running 
times of the procedures called by the procedure EvaluateDiscussion in Algorithm |3J □ 

Proposition A. 2. The procedure EnumerateSCC applied to the transitive closure D c [v] of a discussion 
D[v] (i) does not loop indefinetly, (ii) returns the set of all strongly connected components of D c [v], and (Hi) 
has the running time in 0(V(D c [v]) + L(D c [v])). 

Proof. We do not discuss the detail of the proof as Tarjan's strongly connected components algorithm [TH] 
can be reused as is, or an improved variant thereof can be employed instead (cf., e.g., |f 8j). □ 

Proposition A. 3. The procedure ContractSCC applied to the set C of strongly connected components of 
D c [v] (i) does not loop indefinetly, (ii) returns an acyclic directed graph Dc, in which each vertex represents 
exactly one strongly connected component from C and Dc corresponds to the graph that would be obtained by 
contracting down to a single vertex each strongly connected component in D c [v\, and (Hi) has the running 
time in 0(\C\{\C\ - \)\L(D c [v])\) . 

Proof. ContractSCC always terminates, as the number of strongly connected components is finite, and 
the number of vertices in each of these components is finite. 

We now prove that ContractSCC (ii) returns an acyclic directed graph Dc, in which each vertex 
represents exactly one strongly connected component from C and Dc corresponds to the graph that would be 
obtained by contracting down to a single vertex each strongly connected component in D c [v]. The procedure 
starts by adding as many vertices to Dc as there are strongly connected components in C. As the rest 
of the procedure does not add or remove vertices, |T^(-Dc) equals the number of elements in C. The first 
for each loop will relate, via the function standsFor each vertex in Dc to exactly one strongly connected 
component in C. The second for each loop, and its first inner for each loop will together consider each pair 
of vertices in Dc- For each such pair, the innermost for each loop (cf., Lines 17-21 in Algorithm |SJ will 
add to Dc a line between these two vertices only if there is a line in D c [v] between these two vertices, and 
in the relevant direction. The for each loops in Lines 15 and 16 together with the standsFor ensure that all 
lines in D c [v], which are not within strongly connected components, will be considered. For each such line 
between two strongly connected components, a line will be added to Dc between the vertices that represent 
the two strongly connected components. It follows that Dc corresponds to the graph that would be obtained 
by contracting down to a single vertex each strongly connected component in D c [v] . 

We finally prove that ContractSCC (Hi) has the running time in 0(\C\(\C\-l)\L(D c [v})\). The first for 
each loop has \C\ cases to consider. The second for each loop will consider, for each of the \C\ cases, \C\ — 1 
other case, then at most \L(c)\ lines. The upper bound on the number of operations that the procedure 
will perform is thus \C\ + \C\(\C\ — l)\L(D c [v]\). It follows that the upper bound on running time is in 
0(|C|(|C|-1)|L(£» C H)|). □ 

Proposition A. 4. The procedure TopologicalSort applied to the directed acyclic graph Dc (i) does not 
loop indefinetly, (ii) returns the topological sort of the vertices of Dc, and (Hi) has the running time in 
0(V(D c )+L(D c )). 
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Proof. We do not discuss the detail of the proof as Tarjan's depth- first search algorithm j^D] can be reused 
as is. □ 



Proposition A. 5. The procedure ExpandSCC applied to the sequence Sc (i) does not loop indefinetly, (ii) 
returns the sequence S, which is the topological sort of the strongly connected components of D c [v\, and (Hi) 
has the running time in 0(\C\). 

Proof. Sc has |l^(Z?c) elements, and procedure ContractSCC makes V(Dc) equal to the number of 
strongly connected components in D c [vJ. As D c [v] has a finite number of strongly connected components, 
ExpandSCC alsways terminates. 

It is trivial to see that S, returned by ExpandSCC is the topological sort of the strongly connected 
components of -D c [v]. ExpandSCC first makes S the replica of Sc, then replaces via the function standsFor 
(defined by ContractSCC) each element of S by the corresponding strongly connected component of D c [w]. 

Finally, the for each loop considers each element in S. The number of elements in S equals the number 
of strongly connected components, so that ExpandSCC has the running time in 0(C) □ 

Proposition A. 6. The procedure LabelSCC applied to the transitive closure D c [v] of a discussion D[v] and 
the topological sort S of all strongly connected components of D c [v] (i) does not loop indefinetly, (ii) if there 
are stable c-labels for all vertices in D[v], then a function A : V(D[w]) — ► {A, AD,R}, which returns the 
stable c-label for each vertex in D[v\; if there are no stable c-labels, then an error, and (Hi) has the running 
time in 0(C(D c [v])(\L(D c [v])\ + 2|l/(_D c [v])|)) ; where C(D c [v\) is the number of simple cycles in D c [v\. 

Proof. It is straightforward to sec that the while loop will terminate for any finite S and finite -D c [v], 
since it considers each strongly connected component only once. For each strongly connected component, 
the while loop will call either ComputeLabel or LabelComplexSCC. Proposition 15.271 indicates that 
ComputeLabel always terminates. Proposition lA. 71 indicates that LabelComplexSCC always terminates. 
Consequently, LabelSCC will never loop indefinetly, provided that D c [v] is finite. 

We now prove that if there are stable c-labels for all vertices in D[v], then LabelSCC returns a function 
A : V(£)[V]) — > {A, AD,R}, which returns the stable c-label for each vertex in D[v]; if there are no stable 
c-labels, then an error. The while loop distinguishes simple from complex strongly connected components. 
A strongly connected component c is simple if |V(c)| = 1, and complex otherwise. Given that the while 
loop considers each c according to the topological sort of strongly connected components of -D c [w], the 
procedure ComputeLabel will be called on a simple c only after all strongly connected components that 
precede it obtained stable c-labels for all of their vertices. Consequently, all vertices that are relevant for 
the acceptability of the vertex in the simple c already have stable c-labels when ComputeLabel is called 
on a simple c. Consequently, if ComputeLabel does not return an error when called on a simple c, then 
the only vertex in c will obtain its stable c-label. When the while loop encounters a complex c, it will call 
LabelComplexSCC. Proposition lA. 71 indicates that LabelComplexSCC will return at least two c-labels 
in the c-sequence of each vertex in c, provided that there are stable c-labels for the vertices in c, whereby 
the last c-label of the c-sequence of each vertex in c is its stable c-label. If the calls of ComputeLabel and 
LabelComplexSCC do not return an error, and after all strongly connected components obtained their 
c-labels, the function A : V(D[v}) — > {A, AD, R} is defined in the for each loop in Lines 18-20. 

Finally, we prove that LabelSCC has the running time in 0(C(D c [v])(\L(D c [v])\ + 2\V(D c [v})\)), where 
C(D c [v]) is the number of simple cycles in D c [v]. ComputeLabel^ ■, D c [v\) is in 0(inDegree(v j, D c [v])) 
(cf., Proposition (OH); and the running time of LabelComplexSCC^, Vj) is 0((\L(a)\ + |V r (c i )|)(C(c i ) + 
1) + C(cj)|V(cj)|) (cf., Proposition IA.7j) . The running time will be governed by the labeling of complex 
strongly connected components of -D c [i>], so that the running time of LabelSCC will be in: 

O I E [(1^)1 + \V(c t )\)(C(c t ) + 1) + C(c t )\V( Cl )\] I 

\Ci S.t. C;|>1 J 

In the worst case, every strongly connected component in D c [v] is complex. It follows that the upper bound on 
the time complexity for LabelSCC is 0(C(D c [v])(\L(D c [v])\ + 2\V(D c [v})\)), where C{D c [v}) is the number 
of simple cycles in D c [v] . □ 
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Proposition A. 7. The procedure LabelComplexSCC applied to a complex strongly connected component c 
(i) does not loop indefinetly, (ii) if there are stable c-labels for all vertices in c, then at least two c-labels in the 
c-sequence of each vertex in c, with the last c-label of the c-sequence of each vertex being its stable c-label, an 
error if there are no stable c-labels, and (Hi) has the running time in 0((\L(c)\ + \V(c)\)(C(c) + l)+C(c)\V(c)\), 
where V(c) is the number of vertices, L(c) the number of lines, and C(c) the number of simple cycles in the 
strongly connected component c of the transitive closure D c [v] of the discussion D[v\. 

Proof. We first prove that LabelComplexSCC (i) does not loop indefinetly. The procedure terminates as 
soon as Q empties. There are three ways to empty Q, so that we consider three cases: 

1. ComputeLabel returns an error. This occurs if propagateLabel encounters a disallowed input (cf., 
Line 7 in Algorithm [2J) . Lines 34-36 in Algorithm [5] ensure that Q empties if ComputeLabel returns 
an error. 

2. The last two c-labels on the c-sequence of First are identical (cf, Line 27 in Algorithm^!. This case is 
possible because LabelComplexSCC will traverse First at least once after initialization, and thereby 
add a second c-label. Condition in Line 27 verifies and Q empties, so that the procedure terminates. If 
the last two c-labels in the c-sequence of First are not identical, then the next case applies. 

3. The last two c-labels in the c-sequence of First are not identical (Line 30). The procedure will not 
empty Q until p — 4. Q will therefore be emptied after a finite number of travcrsals of c, so that the 
procedure cannot loop indefinetly 

We now prove that the procedure LabelComplexSCC (ii) if there are stable c-labels for all vertices in c, 
then at least two c-labels in the c-sequence of each vertex in c, with the last c-label of the c-sequence of each 
vertex being its stable c-label, an error if there are no stable c-labels. Three cases must be considered: 

1. c contains a disallowed graph structure. The procedure detects a disallowed graph structure via the 
procedure ComputeLabel. Lines 33-35 in Algorithm [5] ensure that the procedure returns an error 
when the ComputeLabel procedure returns an error. ComputeLabel returns an error if the function 
propagateLabel returns an error, that is, when propagateLabel is given an input other than those listed 
in Table [T] If c contains a disallowed graph structure, then there is no interest in traversing the graph 
any further. The error must be resolved before the labeling is attempted again. 

2. The last two c-labels on the c-sequence of First are identical (Line 27 in Algorithm^. We must prove 
that the labels returned after the condition in Line 28 verifies indeed are the stable labels for all vertices 
in c. We prove this in three steps: 

(a) First, we prove that if there are two c-labels in the c-sequence of First, then each vertex in c 
has at least two c-labels in its c-sequence. We prove this by contradiction. When the procedure 
initializes, it adds the label A to the c-sequence of each vertex in c (cf., Line 5 in Algorithm [5]) . 
The procedure adds First to the queue Q, and enters the while loop. The inner for each loop 
(cf., Lines 12-36) adds c-labels to all vertices on lines that start in First and adds these vertices 
to Q. The outer for each loop (cf., Lines 10-37) guarantees that each of the vertices in Q will 
be traversed by the inner for each loop. The only way for some vertex v x not to obtain a second 
c-label in its c-sequence before First obtains its second c-label is if the inner for each loop misses 
v x , which can only occur if there are no lines in c that end in v x . We know that, in any strongly 
connected component, any vertex is on at least one cycle. It is consequently a contradiction for c 
to be a strongly connected component and have at least one vertex v x that has one c-label in its 
c-sequence when First has two c-labels in its c-sequence. LabelComplexSCC therefore ensures 
that all vertices have at least two c-labels if First has two labels^ 

5 It may be relevant to highlight why we need at least two c-labels in the c-sequence of each vertex after First has two 
c-labels. During initialization, the procedure assigns the c-label A to all vertices. A is chosen because it is the weakest label, 
being overruled by both AD and R (cf., Dcfmition l5.25l l. If Q empties and only a single c-label is assigned to some vertices, then 
we would be assuming that the stable c-label for those vertices is the label A, which was assigned when the procedure initialized. 
We clearly cannot assume that the first c-label in a c-scquence is the stable c-label, because the it is added without considering 
the c-labels on vertices adjecent via incoming lines. 
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(b) It follows from the above that the second c-label is added to the c-sequence of First after all 
vertices and lines in c were visited at least once. The next, third c-label is added to the c-sequence 
of First, as soon as the procedure traverses all other vertices and all lines in c at least once after 
the second c-labcl was added to the c-sequence of First. And so on. In other words, p increments 
(cf . , Line 23 in Algorithm [5]) exactly when the procedure returns to First, having traversed all 
other vertices and all lines in c at least once. It is apparent that if there are stable labels in c and 
are discovered as soon as the the pth c-label is added to the c-sequence of First, then the c-labels 
returned by the procedure for all vertices when the pth c-label is added to the c-sequence of First 
must be identical to all c-labels returned by the procedure when the (p + i)th c-label is added to the 
c-sequence of First, where i > is a positive integer. We prove this claim by induction on i in 
p + i and the number C (c) of simple cycles in c. 

A preliminary remark is in order: The procedure LabelComplexSCC will return a c-label for 
each vertex as soon as the (p — l)th and pth. c-labels in the c-sequence of First are identical. In 
order to add the (p + l)th label when (p — l)th and pth c-labels are identical, we will assume that 
Lines 28-29 do not execute when the pth label is added, which is to say that First will remain in 
Q when the pth label is added. 

i. Suppose that C(c) = 1, i.e., c has a single simple cycle. (Note that, since c is a strongly con- 
nected component, it must have at least one cycle, so that c cannot have CountSimpleCycles(c) = 
0.) If we assume C(c) = 1, all of c's vertices are on that simple cycle (i.e., c has a directed 
Hamiltonian cycled). There is consequently exactly one simple path from any vertex in c to 
any other vertex, and of course, exactly one simple cycle that starts and ends in a vertex. 
Equivalently, there is in c exactly one line, say v'v, that ends in any one vertex, say v. Since 
there are three possible c-labels A, AD, and R on any v', the result of propagateLabel(v' ,v) 
will be any one of these three labels. We can picture c as shown below: 



Given that all vertices are on the same simple cycle, and all vertices other than First must 
be traversed at least once (cf., Point 2. a above) before LabelComplexSCC returns to First, 
we know that as soon as First obtains its pth c-label, all other vertices will have p c-labcls in 
their c-sequences. Suppose that v = First in the graph above, and its (p— l)th and pth labels 
are identical, and observe the following: 

A. propagateLabel(v , v") when v has p labels is identical to propagateLabel(v , v") when v has 
p + 1 labels in its c-sequence; propagateLabel(v" ' , . . .) when v" has p labels is identical to 
propagateLabel(v" , . . .) when v" has (p + 1) labels in its c-sequence; and so on. It ensues 
that propagateLabel(v' , v) when v' has p labels is identical to propagateLahel(v' , v) when v 
has p+ 1 labels in its c-sequence. Now, a vertex in c may have other lines that end in that 
vertex, but which arc in -D c [w], but not in c. They do not influence the observations here, 
beccause the vertices outside c, in which these lines originate, have obtained stable c-labels 
before c is submitted to LabelComplexSCC. This is true by definition of the procedure 
EvaluateDiscussion, as these vertices outside c are in strongly connected components 
other than c; such strongly connected components precede c in the topological sort of the 
strongly connected components of Z) c [i;]. 

B. We obtain the exact same conclusions as above if we replace (p + 1) with (p + 2) and p 
with (p + 1). It is trivial to see that we will obtain the same conclusions when we replace 
(p + i + 1) with (p + i + 2) and (p + i) with (p + i + 1), for any positive integer i > 0. 

It follows then that if c has exactly one simple cycle and has stable c-labels, and they are 
discovered as soon as the the pth c-labcl is added to the c-sequencc of First, then the c-labcls 
returned by the procedure LabelComplexSCC for all vertices when the pth c-labcl is added 
to the c-sequence of First must be identical to all c-labels returned by the procedure when the 
(p + i)th c-label is added to the c-sequence of First, where i > is a positive integer. 



6 A directed Hamiltonian cycle is a cycle in a directed graph that traverses each vertex in the graph exactly once, except for 
the vertex in which the cycle starts and ends (which is visited twice). 
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ii. C(c) = 2, i.e., c has two simple cycles. In order to have the two distinct simple cycles, there 
must be exactly one vertex, say v out in c such that there are exactly two lines that start in 
v out , and there must be exactly one other vertex, say v m in c and exactly two other lines that 
end in v m . c therefore has some variant of the structure shown belowQ 




Suppose that v = First. To add the (j>+ l)th c-label to the c-sequence of First, the procedure 
must traverse at least once all other vertices in c. This is ensured by the if— then block in Lines 
14-25. To see how, suppose that there are more vertices on the path from v out to v m that 
docs not pass through v'" , than there are on the path from v out to v m that does pass through 
v'". When the procedure reaches v out , it will consider separately each branch outgoing from 
v out . We can picture this in the following way. When the procedure computes the number 
of simple cycles, it obtains the upper bound on the number of simple paths from any vertex 
to any other vertex in c. As we have two simple cycles in the graph shown above, we shall 
place two walkers X and Y at the vertex First and assume that each walker takes equal time 
to traverse a vertex and can only go forward in steps of one vertex. The two walkers will 
reach v out at the same time, and take different paths along the branches from v out . One, say 
X is thus sent along the shorter path and the other Y along the longer path. Clearly, X will 
reach v' before Y. Once X reaches v', its next step is First. We do not allow X to add a 
label to the c-sequence of First because some of the information in the graph, i.e., c, is not 
taken into account. Namely, when X entered v m , it computed the c-label on v m by taking 
into account the last c-label in the c-sequences of the vertices v™ and v v . This can be seen 
directly from the ComputeLabel procedure. At that same moment, Y was somewhere on 
the path that ends in v ln . Since Y had yet some vertices to traverse, and thereby their new 
c-labels to compute, Y will add a label to v lv . Since that c-label may be different from that 
assumed by X when X labeled v m , Y may label v m with a different c-label when it gets to v m . 
The procedure is designed so that it waits for all walkers to arrive to First before it appends 
a new c-label to the c-sequence of First. Condition in Line 16 verifies when a walker reaches 
First. Condition in Line 17 verifies if that walker is not the last of the C walkers (i.e., some 
are still on their way to First)] if the considered walker is the C(c)th walker, then we can 
compute the new c-label on First, append its c-sequence, then add First to Q in Line 26 (and 
thereby place new C(c) walkers at the vertex First). Suppose then that we send C(c) walkers 
from First when First has p — 1 c-labels in its c-sequence and this yields a pth c-label in the 
c-sequence of First identical to the (p — l)th label. Since the C(c) walkers traverse the graph 
in the exact same way to add the (p — l)th c-label as they do to add the pth c-label to the 
c-sequence of First, they will proceed in the same way when adding the (p+ l)th label to the 
c-sequence of First. Because the ComputeLabel procedure will be applied on the same pairs 
of vertices and in the same sequence by the different walkers, i.e., the traversal will happen 
in the exact same manner, we conclude that if the procedure returns the same c-labels for all 
vertices when (p — l)th and pth labels in the c-sequence of First are identical, then when the 
algorithm traverses First for the (p + l)th time, it will return same c-labels for all vertices 
as it did when it traversed First for the pth time. The same conclusion can be drawn if we 
replace (p + 1) with (p + 2), p with (p+1), and (p — 1) with p. Finally, it is trivial to see that 
we will obtain the same conclusions when we replace (p + i + 1) with (p + i + 2), (p + i) with 
(p + i + 1), and (p + i — 1) with (p + i) for any positive integer i > 0. 

It follows then that if c has exactly two simple cycles and has stable c-labels, and they arc 
discovered as soon as the the pth label is added to the c-sequcncc of First, then the c-labels 
returned by the procedure for all vertices, when the pth c- label is added to the c-sequence of 

7 The discussion applies to any variant of the shown structure, i.e., any c that has exactly two simple cycles. 
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First, must be identical to all c-labels returned by the procedure when the (p + i)th c-label is 
added to the c-sequence of First, where i > is a positive integer, 
iii. C(c) = n with n > 2, i.e., c has more than two simple cycles. When there are n simple cycles, 
n walkers traverse the graph, and stop before a new c-label is appended to the c-sequence of 
First. Suppose that First has p c-labels in its c-sequence, that the (p — l)th and pth c-labels 
are identical, and that the C walkers are sent from First in order to obtain the (p + l)th 
label in the c-sequence of First. Suppose finally that the (p + l)th and pth label on First are 
identical, but that among the labels returned by the procedure when the (p+ l)th is added to 
First, there is one c-label returned for some vertex other than First that is different from the 
c-label returned for that same vertex when the pth label was added to First. This can only be 
the case if at least one of the walkers did not take the same path at p + 1 as it did at p, which 
in turn can only be the case if the path was modified. In order to modify the path, one needs 
to change the vertices and/or lines and/or (Ay-)labcls on vertices after the last traversal. It is 
therefore a contradiction to have the assumed situation when the C (c) walkers are traversing 
the exact same graph and adding the pth and the (p + l)th c-label to the c-sequence of First. 
Observe that the given conclusion is independent of the value of C(c). It follows that if c 
has exactly C(c) simple cycles and has stable c-labels, and they are discovered as soon as the 
the pth label is added to the c-sequence of First (hence, First's (p — l)th and pth labels are 
identical), then the c-labels returned by the procedure for all vertices when the pth label is 
added to the c-sequence of First must be identical to all c-labels returned by the algorithm 
when the (p + i)th label is added to the c-sequcncc of First, where i > is a positive integer. 

3. The last two c-labels on the c-sequence of First are different (Line 30 in Algorithm^. We must prove 
that no stable c-labels can be found for vertices in c when condition in Line 30 verifies. We prove this 
by induction on p. 

(a) p = 2, i.e., the vertex First has two c-labels in its c-sequence. We have shown in Point 2 above 
that two same c-labels in the c-sequence of First indicate that stable c-labels have been found for 
all vertices in c. We therefore suppose that the (p — l)th and pth c-labels in the c-sequence of 
First are different. Since we set p = 2 here, the first c-label is added at the initialization of the 
procedure and is by default A. As the second c-label must be different from A, it is either AD or 
R. The first column in Table [3] indicates these two possible combinations. That table then lists 
all possible c-labels that will be added after the procedure traverses First for the second and third 
time. The point with Table [3] is that patterns can be spotted with certainty as soon as the fourth 



Table 3: Possible and allowed c-sequence of the vertex First in a strongly connected component c. The procedure 
LabelComplexSCC ensures that the c-labels assigned at each traversal of First depend on the c-label added 
in the last previous traversal. 



Case: 


Assumed c-sequence of First after 


Possible and allowed c-sequences 


Possible and allowed c-sequence 




LabelComplexSCC traverses for 


of First after LabelComplexSCC 


of First after LabelComplexSCC 




the first time the vertex First: 


traverses for the second time the 


traverses for the third time the 






vertex First and given the c- 


vertex First and given the c- 






sequence in the second column: 


sequence in the third column: 


1 


<A,R) 


(A, R, A) 


(A, R, A, R) 


2.1 


<A,R> 


(A, R, AD) 


(A, R, AD, A) 


2.2 


(A,R> 


(A, R, AD) 


(A, R, AD, AD) 


2.3 


(A,R> 


(A, R, AD) 


(A, R, AD, R) 


3 


<A,R) 


(A, R, R) 


(A, R, R, R) 


4 


(A, AD) 


(A, AD, A) 


(A, AD, A, AD) 


5 


(A, AD) 


(A, AD, AD) 


(A, AD, AD, AD) 


6.1 


(A, AD) 


(A, AD, R) 


(A, AD, R, A) 


6.2 


(A, AD) 


(A, AD, R) 


(A, AD, R, AD) 


6.3 


(A, AD) 


(A, AD, R) 


(A, AD, R, R) 



c-label is added to the c-sequence of First. These patterns allow us to say whether there are stable 
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labels in g. We see that one traversal is not conclusive: the first and second label differ and we 
cannot anticipate on this alone what the third label will be. We therefore perform an additional 
traversal of First, which leads to the following case. 

(b) p = 3, i.e., the vertex First has three c-labels in its c-sequence. The third column lists the possible 
combinations of c-labels when there are three c-labels in the c-sequence of First. These are the 
allowed cases when we assume that the first two c-labels are different. We see immediately the 
pattern in case 1: the traversal that started from A gave R and the second traversal gave A. The 
third traversal can only yield R. The only way for this not to happen is to have at least one 
different path to First different from any path traversed when the preceding c-label was added. A 
different path can only be present if the graph was modified after the first traversal. It is therefore 
a contradiction that a different path is present and that the graph is identical. This same rationale 
applies to the remaining cases 2.1-6.3. We see that first two different c-labels in the c-sequence 
of First can yield stable c-labels after the second traversal, if the second traversal yields c-labels 
shown in cases 3 and 5. In other cases, namely 2.1-2.3 and 6.1-6.3, all three different labels appear 
in all three first slots in the c-sequence of First. To spot the pattern there, we need to perform 
the third traversal of the vertes First. 

(c) p = 4, i.e., the vertex First has four c-labels in its c-sequence. The fourth column lists the possible 
combinations of c-labels when there are four c-labels in the c-sequence of First. These are the 
allowed cases when we assume that the first two c-labels are different, and we have the third c- 
label as given in the third column. We immediately see the patterns for cases 2.1-2.3 and 6.1-6.3, 
where patterns could not be spotted after the second traversal of First. In 2.1 the pattern that 
will repeat is A, R, AD; in 2.2 the labels are stable; in 2.3 the pattern is R, AD. In 6.1 the pattern 
is A, AD, R; in 2.2 the patter is AD, R; in 6.3 we have stable labels in g. Table [3] provides all 
patterns when three distinct labels are available and the first two c-labels in the c-sequence of 
First are assumed different. If the first two c-labels are the same, we have immediately identified 
the pattern that gives us stable labels for vertices in c. 

(d) p = (4 + 1) for the positive integer i > 0, i.e., the vertex First has more than four c-labels in its 
c-sequence. We have seen in the preceding case, when p = 4 that we can immediately anticipate 
the fifth c-label as soon as we have the first four. Patterns identified after the third traversal, 
when p — 4 will repeat because the C walkers will traverse the same graph and produce the same 
results as in their prior traversals. We have indeed seen by contradiction in Point 3.b above that 
the next traversal will behave in the manner consistent with the previous ones. It follows that 
once we have reached the fourth c-label in the c-sequence of First and the last two c-labels in that 
c-sequence are not identical, no further traversals should be performed and the conclusion is the 
absence of stable c-labels in c. 

We finally prove that the procedure LabelComplexSCC in Algorithm [5] (in) has the running time in 
0((\L(c)\ + \V(c)\){C(c) + 1) +C(c)\V(c)\). Let c = (V(c),L(c)). LabelComplexSCC first computes the 
number C(c) of simple cycles via Johnson's algorithm [9] in 0((\L(c)\ + \V(c)\)(C(c) + 1)). 

The worst case complexity of the while loop is when c is a strongly connected tournament that has 
no stable c-labels. That c is a tournament means that for any pair Vi,Vj in V(c), either ViVj £ L{c) or 
VjVi £ L(c). We take a strongly connected tournament for the worst case because it has the maximal number 
of simple cycles. A classical result is that a strongly connected tournament on n vertices has a cycle of length 
k, k, for k = 3,4, . . . , n JTT] . When c is a strongly connected tournament on \V(c)\ vertices, it has a cycle of 
length k, for k = 3, 4, . . . , V(c) \ . The number of different lengths of simple cycles in c is then V (c) | — 2, while 
the number C(c) of distinct simple cycles in c is above |T^(c)| — 2, as there can be more than one distinct 
simple cycle of the same length. Let C(c)k be the number of distinct simple cycles in c of length k, so that: 

|V(c)| 

C = C(c) k 

fc=3 

is the number of distinct simple cycles in c. Another classical result is that a strongly connected tournament 
has a Hamiltonian cycle [2], so that C\v( c )\ = 1- Say now that we send C(c) walkers from the vertex First, 
that is, we apply LabelComplexSCC and consider only the number of operations needed to add the second 
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c-label to the c-sequcncc of First. Since C(cW( c ) = 1, a single walker, call it H, will move along the 
Hamiltonian cycle. This being the longest simple cycle in c, H will be the last of the C(c) walkers to arrive 
at the vertex First, and it is upon the arrival of H that the second c-label will be added to the c-sequence of 
First. H will traverse |V(c)| vertices and that same number |V(c)| of lines along the Hamiltonian cycle. It 
is important to observe that First may, but need not be on all simple cycles in c. (This is because a strogly 
connected tournament c need not have a vertex that is on all simple cycles.) Consider another walker, say 
X, moving along a cycle of length, say ^|y(c)|. We have the following two cases: 

1. if First is on the cycle traversed by X, then X will traverse that cycle only once before H reaches First; 

2. if First is not on the cycle traversed by X, then X will traverse that cycle three times before H reaches 
First. 

The second case above is clearly worse in terms of time complexity than the first, as the same cycle will 
be visited three times intead of only once. For any given walker, the worst case is to traverse ^ times 
its cycle of length k. The more times the walkers traverse their respective cycles, the higher the number 
of operations that will be performed before the procedure LabelComplexSCC terminates. It follows that 
the upper bound on the number of operations that all C(c) walkers will perform before the second c-label is 
added to the c-sequence of First is: 

\V(c)\ 

J2 2^C(c) k k = 2C(c)\V(c)\ 

k=3 K 

It is in fact impossible to have the case where the above holds, i.e., where the procedure will traverse 
times each simple cycle of length k. This makes the above a much too pessimistic estimate of the time 
complexity, but lets us avoid styding the relationship between the position of First on more cycles than the 
Hamiltonian cycle in c, which affects the number of times each walker will traverse its own cycle. If there are 
no stable c-labels in c, the procedure will perform three times the number 2C(c)|l / (c)| of operations, as it 
must add three c-labcls to the c-sequence of First. We therefore conclude that the procedure has the running 
time in 0((|i(c)| + \V(c)\)(C(c) + 1) + C(c)\V(c)\). □ 



45 



References 

[1] B. Boehm, P. Grunbacher, and R. O. Briggs. Developing groupware for requirements negotiation: Lessons 
learned. IEEE Software, 2001. 

[2] P. Camion. Chemins et circuits hamiltoniens des graphes complets. C. R. Acad. Sc. Paris (A), 249:2151- 
2152, 1959. 

[3] C. Chesnevar, J. McGinnis, S. Modgil, I. Rahwan, C. Reed, G. Simari, M. South, G. Vreeswijk, and 
S. Willmott. Towards an argument interchange format. Knowl. Eng. Rev., 21(4):293-316, 2006. 

[4] J. Conklin and M. L. Begeman. gibis: a hypertext tool for exploratory policy discussion. ACM Trans. 
Inf. Syst, 6(4):303-331, 1988. 

[5] R. Darimont and A. van Lamsweerde. Formal refinement patterns for goal-driven requirements elabo- 
ration. In SIGSOFT FSE, pages 179-190, 1996. 

[6] Phan Minh Dung. On the acceptability of arguments and its fundamental role in nonmonotonic reason- 
ing, logic programming and n-person games. Artif. Intell., 77(2):321-358, 1995. 

[7] V. Gervasi and B. Nuseibeh. Lightweight validation of natural language requirements. Software — Practice 
& Exp., 32:113-133, 2002. 

[8] J. A. Goguen and C. Linde. Techniques for requirements elicitation. In Proc. Int. Symp. Req. Eng., 
pages 152-164, 1993. 

[9] Donald B. Johnson. Finding all the elementary circuits of a directed graph. SIAM Journal on Computing, 
4(l):77-84, 1975. 

[10] I. Jureta and S. Faulkner. Tracing the rationale behind uml model change through argumentation. In 
26th Int. Conf. on Conceptual Modeling (ER), pages 454-469, 2007. 

[11] I. J. Jureta, S. Faulkner, and P-Y. Schobbens. Justifying goal models. In IEEE Int. Req. Eng. Conf., 
pages 116-125, 2006. 

[12] I. J. Jureta, S. Faulkner, and P-Y. Schobbens. Clear justification of modeling decisions for goal-oriented 
requirements engineering. Requir. Eng., 13(2):87-115, 2008. 

[13] Donald E. Knuth. The Art Of Computer Programming, volume 1. Boston: Addison- Wesley, 3rd edition, 
1997. 

[14] J. C. S. P. Leite and P. A. Freeman. Requirements validation through viewpoint resolution. IEEE T. 
Softw. Eng., 17(12):1253-1269, 1991. 

[15] P. Louridas and P. Loucopoulos. A generic model for reflective design. ACM Trans. Softw. Eng. 
MethodoL, 9(2):199-237, 2000. 

[16] M. McGrath. Propositions. In Edward N. Zalta, editor, The Stanford Encyclopedia of Philosophy. Fall 
2008. 

[17] J. W. Moon. Topics on Tournaments. Holt, Reinhart & Winston, 1968. 

[18] Esko Nuutila and Eljas Soisalon-Soinincn. On finding the strongly connected components in a directed 
graph. Inf. Process. Lett, 49(1):9-14, 1994. 

[19] Robert Tarjan. Depth-first search and linear graph algorithms. SIAM Journal on Computing, 1(2):146- 
160, 1972. 

[20] Robert E. Tarjan. Edge-disjoint spanning trees and depth-first search. Acta Informatica, 6(2):171-185, 
1974. 



46 



[21] S. Uchitcl, R. Chatlcy, J. Kramer, and J. Magee. Goal and scenario validation: a fluent combination. 
Req. Eng., 11:123-137, 2006. 

[22] P. Zave. Classification of research efforts in requirements engineering. A CM Corn-put. Surv., 29(4):315- 
321, 1997. 



47 



